Système d'exploitation pour capteur en réseau
Les systèmes d’exploitation pour capteur en réseau (notés également WSN) sont des systèmes d'exploitation embarqués au sein de capteurs en réseau (le plus souvent des réseaux sans fil). Un capteur en réseau (qu'on retrouve dans les publications scientifiques sous le terme anglais mote) est un ensemble d’éléments électroniques de taille réduite, composé essentiellement d'un détecteur, d'un microcontrôleur, d’une batterie, d'un émetteur-récepteur et d'une antenne.

Un capteur assure trois fonctions : capter une donnée, la traiter et renvoyer une information relative à la donnée au gestionnaire du réseau. Les données sont des grandeurs physiques de l'environnement dans lequel se trouve le capteur. L'intérêt de la configuration en réseau est de capter un grand nombre de données afin d'alimenter une application. L'application réagit en fonction des données remontées par les capteurs et informe sur un changement d'état de l'environnement surveillé. Un capteur a une durée de vie limitée par sa batterie. Le réseau de capteurs doit être résilient pour compenser la fin de vie de chaque capteur.

Les systèmes d'exploitation pour capteurs en réseau sont spécifiquement conçus pour optimiser l'usage des ressources matérielles limitées dont ils disposent : peu de mémoire RAM, une vitesse de traitement processeur faible et peu d'énergie électrique. De nombreux systèmes d'exploitation spécialisés existent, parmi lesquels : Contiki, ERIKA Enterprise, Nano-RK, TinyOS, MantisOS, RETOS, Senses, Cormos, LiteOS, NanoQplus.

Contexte technologique 
Le capteur constitue la partie matérielle que doit gérer le système d’exploitation. Un capteur, ou nœud, est composé de plusieurs éléments ou modules correspondant chacun à une tâche particulière d’acquisition, de traitement, de stockage ou de transmission de données. Il comprend également une source d’énergie.

Les éléments constitutifs du capteur sont les suivants : 
 un détecteur  Le détecteur est l'élément qui capte la grandeur physique de l'environnement dans lequel a été placé le capteur.
 un convertisseur analogique numérique  Le convertisseur analogique transforme le signal capté en signal numérique, compatible avec le micro-contrôleur.
 un micro-contrôleur  Le micro-contrôleur traite les données reçues du convertisseur analogique-numérique et transmet les données utiles à l'émetteur-récepteur.
 de la mémoire  Deux types de mémoire coexistent dans un capteur. La mémoire vive (RAM ou SRAM) permet le fonctionnement de l’application. La mémoire morte (principalement de la mémoire flash) stocke le système d’exploitation et les données traitées par le capteur.
La taille typique de la  mémoire RAM est de l’ordre de , alors que la taille de la mémoire flash atteint quelques Mo.
 un transmetteur radio  L'émetteur-récepteur assure 2 fonctions : transmettre des signaux (émetteur) et recevoir des signaux (récepteur).
 L'émetteur envoie les données vers le monde extérieur. Le monde extérieur est le réseau de capteur, dont le rôle est de router l'information vers l'utilisateur final.
 Le récepteur reçoit les informations du réseau : d'une part les mises à jour logicielles, d'autre part les informations d'autre capteurs à relayer vers l'utilisateur final.
 une alimentation  L'alimentation fournit l'énergie nécessaire au fonctionnement du capteur.

On trouve sur la page List of wireless sensor nodes une liste non exhaustive des matériels utilisés comme capteurs.

Rôle du système 

Le système d'exploitation est un gestionnaire de ressources pour les systèmes complexes. Dans un système typique, ces ressources comprennent un ou plusieurs processeurs (ou CPU), de la mémoire vive, de la mémoire morte, un ordonnanceur (ou en anglais timer) , des disques de stockage, des interfaces utilisateur tels que souris, clavier, imprimantes et écrans, et une ou plusieurs interfaces réseau. Le rôle du système d'exploitation est de gérer l'allocation de ressource processeur pour l'exécution des processus, en maximisant l'utilisation globale du processeur tout en optimisant l'interactivité de ces ressources aux utilisateurs d'une manière ordonnée et contrôlée.

Un réseau de capteur consiste en un grand nombre de nœuds de petite taille alimentés par une batterie. Ils sont limités par la capacité de la batterie, la puissance du processeur et la capacité de communication.
Le rôle du système d’exploitation pour capteur en réseau est d’être l’interface entre des ressources matérielles limitées et des applications distribuées (en anglais Distributed applications). Il doit fournir une variété de services systèmes basiques comme gérer l’allocation de ressource sur les périphériques de matériels divers, interrompre la gestion et la planification de tâches, gérer le réseau support. Le but est de faciliter la programmation des applications, mais aussi d’optimiser les utilisations de ressources.

Les systèmes d'exploitation pour réseau de capteurs sans fil tels que TinyOS, Contiki, SOS, MantisOS, Nano-RKsont conçus pour répondre à ces contraintes.
Les possibilités matérielles des capteurs sont limitées en mémoire, en puissance de calcul et en autonomie énergétique (batterie). Les systèmes d’exploitation doivent avoir une « faible empreinte mémoire » afin d'être embarqués dans la mémoire flash des capteurs. Malgré ces limites matérielles, les capteurs doivent intégrer les fonctionnalités de base d'un système d’exploitation telles que :
 l’allocation de mémoire (RAM, EEPROM);
 le système de fichiers;
 le contrôle d'exécution de code;
 le chargement, le lancement et la gestion des applications;
 la transmission de données;
 la gestion de l’énergie.
Ils doivent en plus gérer les spécificités propres aux systèmes d'exploitation pour capteur en réseau :
 la gestion efficace de l’énergie;
 la fiabilité du système d'exploitation;
 une faible empreinte mémoire;
 la reconfiguration du système d'exploitation;
 le support de protocole de routage optimisé (µIP, Rime, µIPv6);
 le support Temps-réel.

Le protocole µIPv6 permet de réduire la consommation d’énergie dans le processus de routage par rapport au protocole IPv4.

Principes architecturaux

Généralités 
Nous présentons ici une classification des concepts importants de la conception d'un système d'exploitation pour capteur en réseau, dont nous détaillons ci-dessous les rubriques concernant l'architecture, le modèle d’exécution, la programmation, l'ordonnancement et la gestion énergétique.

Architecture 
L'organisation d'un système d'exploitation constitue sa structure. L'architecture d'un système d'exploitation a une influence sur la taille du noyau ainsi que sur la façon de fournir des services aux programmes d'application. Selon Muhammad Omer Farooq et Thomas Kunz, il existe quatre types d'architectures de système d'exploitation connus : l'architecture monolithique, l'architecture micro-noyau, l'architecture en couches et l'architecture en machine virtuelle.

 Monolithique 
Une architecture monolithique ne dispose pas de structure telle que décrite dans les principes architecturaux. Les services fournis par le système d'exploitation sont mis en œuvre séparément et chaque service fournit une interface pour d'autres services. Ce type d'architecture permet le regroupement de tous les services requis pour former une seule image système. Il en résulte une empreinte mémoire réduite du système d'exploitation. Un avantage de l'architecture monolithique est que les coûts d'interaction du module sont faibles. Par contre le système est difficile à comprendre et à modifier, peu fiable et difficile à maintenir. Les inconvénients des noyaux monolithiques en font de mauvais candidats pour la conception des systèmes d'exploitation des capteurs contemporains.

 Micro Noyau 
Dans une architecture micro-noyau, le noyau fournit le strict minimum pour assurer le fonctionnement du système. La taille du noyau s'en trouve considérablement réduite. La plupart des fonctionnalités du système d'exploitation est fournie via des serveurs au niveau utilisateur comme un serveur de fichiers, un serveur de mémoire, un serveur de temps, etc. Si un serveur tombe en panne, l'ensemble du système ne s'arrête pas de fonctionner. L'architecture micro-noyau présente une meilleure fiabilité, une facilité d'extension et de personnalisation. L'inconvénient majeur d'un micro-noyau est sa performance médiocre en raison des aller-retours fréquents entre le noyau et l'utilisateur. Cependant, grâce à la petite taille de son noyau, ce type d'architecture est privilégié par de nombreux systèmes d'exploitation embarqués.

 Modulaire ou composant 
Dans une architecture modulaire (ou en couches) le système d'exploitation met en œuvre des services sous la forme de couches. Les avantages de cette architecture sont la portabilité, la simplicité structurelle et la fiabilité. Par-contre cette architecture n'est pas très flexible.

 Machine virtuelle 
Le principe d'une machine virtuelle est d'intégrer le système d'exploitation à l'application de l'utilisateur. Une machine virtuelle possède toutes les caractéristiques matérielles requises. Le principal avantage est sa portabilité, mais l'inconvénient majeur est typiquement un mauvais rendement du système.

Modèle d’exécution 
Le modèle de programmation supporté par un système d'exploitation a un impact significatif sur le développement d'applications.

 Événementiel (Event-based)  Le modèle évènementiel donne la priorité aux évènements. Un évènement préempte les ressources jusqu’à ce qu’il soit terminé. La survenue d’un évènement par nature est asynchrone. Les tâches de gestion courante peuvent être interrompues par la survenue d’un évènement, mais pas l’inverse.

 Multi Thread (Thread-based)  Un thread est un élément de calcul de base. Il a son propre état. Le modèle mulri-thread donne de la flexibilité dans l'écriture d'applications. Une application consiste en l’exécution d’un ensemble de threads. Les tâches dévolues au réseau ou à l’ordonnanceur sont également des threads. Lorsqu’un thread est exécuté les autres sont bloqués. Le noyau gère une table de threads avec des règles de priorité et un système de tour de rôle (Round-robin).

 Hybrid  Un système hybride bénéficie des avantages des 2 modèles précédents. Les threads sont synchronisés alors que les évènements surviennent de manière asynchrone.

Reprogrammation 

La reprogrammation est la capacité d'un système à pouvoir évoluer. Permet la mise à jour dynamique du logiciel s'exécutant sur les nœuds de capteurs. C'est une fonctionnalité importante du fait de l'inaccessibilité physique des capteurs et du nombre important de capteurs que peut constituer le réseau. Cette opération peut être réalisée à différents niveaux du système d'exploitation. Une reprogrammation peut intervenir à l’échelle de l’application, à l’échelle du module (ou composant) et à l’échelle de l’instruction (ou variable). Une reprogrammation consomme de la ressource réseau, en proportion du niveau à laquelle elle se situe. On peut ainsi ajouter, modifier ou supprimer un module, composant ou application du système d'exploitation. Les données sont envoyées par fréquence radio est acheminées grâce aux protocoles réseaux, de nœud en nœud jusqu'au capteurs, cette opération est évidemment couteuse en énergie, et c'est le rôle du protocole réseau d'optimiser cette consommation d’énergie. Après la réception du code au niveau des nœud, il faut soit ajouter ou mettre à jour l'actuel logiciel fonctionnant. Cela nécessite un mécanismes de gestion de la mémoire. Pour mettre à jour les capteurs le système doit allouer dynamiquement la mémoire pour faciliter le chargement des composants logiciels au moment de l'exécution
.

Ordonnancement 
L'ordonnancement détermine l'ordre dans lequel les tâches sont exécutées sur un CPU. Dans les systèmes informatiques traditionnels, l'objectif d'un ordonnanceur est de minimiser la latence, pour optimiser l'utilisation de la bande passante et des ressources, et pour assurer l'équité. Le choix d'un algorithme d'ordonnancement adapté aux réseaux de capteurs dépend généralement de la nature de l'application. Pour les applications ayant des exigences temps réel, un algorithme d'ordonnancement en temps réel doit être utilisé. Pour d'autres applications, les algorithmes d'ordonnancement non-temps réel sont suffisantes. Les capteurs pour réseau sont utilisés dans des environnements à la fois en temps réel et non temps réel, Le système d'exploitation pour capteur en réseau doit fournir des algorithmes d'ordonnancement qui répondent aux exigences des applications. Par ailleurs, l'algorithme d'ordonnancement à un impact sur la gestion de la mémoire et l'efficacité de la consommation énergétique.
Il existe deux catégories d'ordonnancement des taches :
 l'ordonnancement en temps réel
Ce mode de fonctionnement permet de répondre aux besoins d'application en temps réel pour la surveillance d'environnement de manière périodique. Il permet l’exécution des tâches au fil de l'eau.
 l'ordonnancement en temps partagé
L'ordonnancement des tâches en mode événementiel, convient pour des évènements asynchrones.

Algorithmes d'ordonnancement 
 
 Round-robin (ou méthode du tourniquet)
 Rate-monotonic scheduling (RMS)
 Earliest deadline first scheduling (EDF)
 FIFO
 Shortest job first (SJF, ou SJN -Shortest Job Next-)
 Completely Fair Scheduler (CFS)

Gestion de l'énergie 
Les nœuds sont par définition alimentés par une batterie. La gestion de l'énergie est un facteur important dans la conception d'un système d’exploitation pour capteur en réseau. Selon Wei Dong, les techniques actuelles pour économiser l'énergie sur des nœuds peuvent être différenciées entre la gestion énergétique des microcontrôleurs et la gestion énergétique des périphériques.
 Gestion énergétique des microcontrôleurs
Les microcontrôleurs sont typiquement un ensemble de composants à faible consommation permettant de garder actif des périphériques différents.
Klues propose ICEM pour gérer le contrôle d'accès simultanés et la gestion de l'énergie des pilotes de périphériques : chaque microcontrôleur a une fonction de veille qui calcule l'état de puissance minimale requise pour laisser actifs les sources d'interruption et les périphériques du circuit intégré. Le système d’exploitation se contente de calculer la puissance nécessaire en gérant un bit spécifique. Le calcul d'état de veille permet également à un pilote de spécifier un état de veille minimale garantie.
 La gestion énergétique des périphériques
La gestion énergétique des périphériques exige de connaître le modèle d'utilisation de l’application. Chaque périphérique est éteint individuellement quand il n'est pas utilisé. Bien que pour des périphériques dédiés, il soit assez simple de contrôler les états de puissance par des applications, pour des périphériques virtualisés et partagés, c'est de la responsabilité de l'OS de gérer l’énergie pour tout le système. ICEM exploite la concomitance des entrées-sorties d'application et propose un mécanisme de blocage de la puissance pour automatiquement minimaliser la consommation d'énergie en l'absence d'informations supplémentaires sur une application. Parmi les périphériques du nœud, l'émetteur-récepteur est le plus énergivore. Le protocole Contrôle d'accès au support est le plus pertinent pour la gestion de la consommation énergétique de périphérique radio. Le protocole MAC et la couche réseau doivent être optimisés afin que l'énergie utilisée soit directement employée au trafic généré et non au temps de travail complet. D’autres propriétés importantes sont l'adaptabilité à la topologie de réseau, en ce qui concerne le nombre de nœuds et la densité.
Plusieurs protocoles dérivés du protocole MAC comme (S-MAC, B-MAC, X-MAC), permettent le stockage, le routage ou la dissémination de données. Ces protocoles se comportent comme des architectures de système à étages, et la dispersion aléatoire des nœuds ne pose pas de problème.

Avec une source d'énergie finie, tous les paramètres de performance ne peuvent pas être optimisés simultanément. Par exemple, l'utilisation d'une batterie de meilleure capacité implique un coût supplémentaire, le cycle d'utilisation (duty cycle) bas se traduit par une dégradation de la fiabilité, l'utilisation d'une puissance supérieure des émetteurs-récepteurs se traduit par une plus grande consommation, et à l'inverse la réduction de la puissance conduit à un déploiement en plus grand nombre des capteurs.

Une technique alternative a été appliquée pour tenter de résoudre le problème de durée finie de fonctionnement d’un nœud, c'est l'utilisation de la « récupération d'énergie » (Récolte d'énergie). La récupération d'énergie se base sur l'exploitation de l'énergie de l'environnement ou d'autres sources d'énergie (ex : la chaleur d’un corps) qui est convertie en énergie électrique pour alimenter le nœud. Dans le meilleur des cas, il est possible d'avoir un bilan énergétique positif en faveur du nœud, ce qui se traduit par une durée de vie théoriquement illimitée .

Historique 

 TinyOS  TinyOS est un système principalement développé et soutenu par l'université américaine de Berkeley. La version 0.6.1 apparaît en .

 Contiki  Contiki, est un système développé et soutenu par l'Institut d'Informatique Suédoise. Adam Dunkels est l'initiateur du projet.

 Mantis OS  Mantis, est un système principalement développé et soutenu par l'université américaine de Colorado. La version 0.9.5 apparait en . La version 1.0 beta apparaît en .

 Nano-RK 

 RETOS  RETOS est un système développé par l'Université Yonsei en Corée. La version 1.1.0 apparaît en .

 LiteOS  LiteOS est un système développé et soutenu par l'Université américaine de l'Illinois à Urbana-Champaign. La version 0.3 apparaît en .

 SenOS 

 EYES/PEEROS 

Autres Systèmes d'exploitation :
 t-Kernel, DCOS, MagnetOS, kOS, SenOS, VMSTAR, OSSTAR, Nano-QPlus, CORMOS, MagnetOS, kOS, T2

Systèmes existants 
Un état de l'art de mai 2010 recense les principaux systèmes d'exploitation pour capteur en réseau et décrit les solutions apportées par chacun pour optimiser la gestion énergétique des capteurs. Une classification des différents systèmes d'exploitation est également dressée. L'article de 2007 complète celui de 2010 en décrivant d'autres systèmes d'exploitation tombés en désuétude mais intéressants concernant les stratégies utilisées pour optimiser la consommation d’énergie des capteurs. Enfin, deux autres articles, de 2010 et 2011, font le point sur les versions récentes de ces systèmes. Ces articles font ressortir cinq systèmes d'exploitation - TinyOs, Contiki, Mantis, Nano-RK, et LiteOS - sur lesquels nous expliciterons plus en détail les stratégies développées.
Le type d'architecture utilisé pour les systèmes d'exploitation qu'il soit à noyau monolithique, micro-noyau, modulaire ou machine virtuelle, a un impact direct sur la taille du noyau, son empreinte mémoire. L'architecture monolithique permet de réduire cette empreinte au détriment de la simplicité d'utilisation. L'architecture en machine virtuelle permet une portabilité simplifiée du système d'exploitation, le rendant plus flexible sur différents capteurs mais au détriment de la performance. L'architecture modulaire, quant à elle, permet une simplicité d'utilisation et de compréhension, mais la flexibilité en pâtit.
Par rapport aux systèmes monolithiques, les micro-noyaux répondent à un besoin de modularité, de flexibilité et de sécurité (Liedtke, 1996). La performance des mécanismes de communication entre les serveurs est au cœur de la conception de tous les micro-noyaux. L'inconvénient majeur réside dans le fait que tout mécanisme de reconfiguration dynamique est à inclure par le concepteur au-dessus de ces services.

Systèmes pour réseaux de capteurs 
Apparus récemment(Hill et al., 2000), les nœuds de réseaux de capteurs ont la particularité d’être des systèmes très contraints en ressources, nécessitant des systèmes d’exploitation léger et efficaces. De par la nature de leur déploiement, souvent difficilement accessible physiquement, la reconfiguration dynamique des systèmes d'exploitation est essentielle, néanmoins peu d’entre eux disposent de cette capacité. Pour la plupart, ces systèmes remontent des événements de capteurs de manière périodique, étant en veille la plupart du temps. Par conséquent les mécanismes de mise à jour se limitent souvent à une réécriture de l’image du système et au redémarrage du système (avec perte éventuelle d'un état), comme Mantis (Bhatti et al., 2005).
Les capteurs communiquant entre eux au sein du réseau, il est important que les systèmes d'exploitation fournissent une interface de programmation en s'appuyant de façon efficace sur le protocole de communication. L'ordonnanceur à un rôle important car il doit optimiser l'utilisation de la mémoire pour avoir un rendement énergétique optimal.

TinyOS 

TinyOS (Hill et al., 2000) a été l’un des premiers systèmes d'exploitation conçus pour les réseaux de capteurs. Les systèmes à composants TinyOS sont construits à la carte, en langage nesC .
(Gay et al., 2003). TinyOS est un système événementiel. Il n’est pas reconfigurable, néanmoins plusieurs approches existent pour permettre la reconfiguration des applications. XNP (Jeong et al., 2003) permet de télécharger et réinstaller une nouvelle image système en effectuant un redémarrage. FlexCup (Marron
et al., 2006) permet la reconfiguration dynamique à l'échelle des applications. Le mécanisme de FlexCip est basé sur des méta-données générées pendant la compilation du système qui permettent à un éditeur de liens embarqués de modifier le système pendant l’exécution. Cette approche nécessite le partitionnement d’une application en plusieurs composants, chacun dans un segment mémoire séparé. FlexCup permet de minimiser la consommation d’énergie des capteurs sur lesquels le système est modifié.

TinyOS est un système d'exploitation intégré, modulaire. Cette plate-forme logicielle ouverte, ainsi qu'une série d'outils, développés à la base par l'Université de Berkeley sont enrichis par une multitude d'utilisateurs. En effet, TinyOS est le plus répandu des OS pour les réseaux de capteurs sans-fil.
TinyOS a une empreinte mémoire de 4Ko. La bibliothèque de composants TinyOS comprend des protocoles réseau, des applications de services distribués, des drivers de capteurs et des outils d'acquisition de données.
La contrainte énergétique due à l'autonomie des capteurs implique l'utilisation de puissances de calcul réduites entraînant le développement de logiciels contraint par la capacité de la mémoire et par la vitesse d'exécution. L'utilisation du langage nesC permet d'optimiser le code et ainsi réduire l'usage de la RAM. La tendance actuelle est de concevoir des réseaux de capteur, dont chaque nœud doit disposer d'une autonomie de plusieurs jours ou plusieurs années.
Les principaux systèmes embarqués candidats pour être utilisés par les capteurs sont TinyOS et Contiki. Le premier est développé conjointement par l'université Berkeley et la société Intel, et était précédemment le plus utilisé dans le domaine des systèmes micro-embarqués. Cependant, il souffre de quelques défauts, dont certains sont résolus par Contiki. Par exemple, il ne supporte pas le chargement modulaire de parties du logiciel, ce qui impose l'envoi du code binaire complet lors d'une mise à jour à distance. Ce mode fonctionnement n'est pas sans conséquences : l'énergie étant limitée sur un capteur sans-fil, la dépence énergétique est proportionnelle au volume de code téléchargé.
Maté (Levis & Culler, 2002) est une machine virtuelle construite avec TinyOS. Les applications Maté sont construites avec un ensemble restreint d’instructions de la machine virtuelle, arrivant à des applications très compactes. Le système permet uniquement une mise à jour d’applications de la machine virtuelle. De cette façon, l’approche Maté optimise l’utilisation de la ressource la plus critique. La consommation d’énergie de l’interface radio. Par contre, dû à l’approche de machine virtuelle, Maté
présente un impact sur les performances d’un système.

Architecture 
TinyOS s'inscrit dans la catégorie des architectures monolithiques. TinyOS utilise le modèle de composant conformément aux exigences d'une application, ensemble de composants logiciels qui peuvent être conditionnés en un seul exécutable sur un capteur. Les différents composants sont compilés ensemble avec l'ordonnanceur pour exécuter du code portable et réutilisable, sans perdre de performance au moment de l'exécution puisque l'application monolithique est le modèle qui exploite au mieux les ressources disponibles. Un Composant est un constituant de base d'une application nesC. Il existe deux types de composants : les modules et les configurations
 Module : composant qui implémente une ou plusieurs interfaces ;
 Configuration : composant qui relie d'autres composant ensemble.
Une interface définit d'une manière abstraite les interactions entre deux composants. Les interfaces sont bidirectionnelles, elles spécifient un ensemble de fonctions à implémenter par les composants fournisseurs de l'interface (commands), et un ensemble de fonctions à implémenter par les composants utilisateurs de l'interface (events). Les commandes font typiquement des appels du haut vers le bas (des composants applicatifs vers les composants plus proches du matériel), alors que les events remontent les signaux du bas vers le haut. Un module est un composant qui implémente une ou plusieurs interfaces et peut utiliser une ou plusieurs interfaces. La mise en œuvre des composants s’effectue en déclarant des tâches, des commandes ou des évènements. Les commandes et les événements sont des mécanismes de communication entre les composants. Une commande est une demande pour exécuter un certain service, alors que l'événement marque la fin du service. TinyOS fournit une pile de partage unique. Il n'existe pas de séparation entre l'espace noyau et l'espace utilisateur. La figure 2 décrit l'architecture de TinyOS.

Modèle de Programmation 
Le développement des applications s'appuyant strictement sur le modèle de programmation événementiel n’a pas permis l'émergence du Multithreating sur les premières versions de TinyOS. Depuis la version 2.1 TinyOS prend en charge le multithreading. Les sous-processus sont appelés threads TinyOS TOS. Dans [6], Les auteurs ont souligné une problématique : compte tenu des contraintes de ressources des capteurs, un système d'exploitation basé sur des événements génère une plus grande concurrence (deux processus qui veulent accéder a une même donnée). Toutefois, le multitâches préemptif offre un modèle de paradigme de programmation intuitif (style fondamental de programmation informatique). L'ensemble TOS threading offre un modèle de programmation threading couplé avec l'efficacité d'un noyau évènementiel (event driven). Les threads TOS sont compatibles en amont avec le code TinyOS existant. Threads TOS utilise une approche multitâche coopératif c'est-à-dire que chaque processus doit explicitement permettre à une autre tâche de s’exécuter et s'appuie sur des applications TOS pour augmenter le rendement du processeur. Cela ajoute une charge supplémentaire pour le programmeur qui doit gérer la concurrence. Les Threads des applications dans TinyOS peuvent préempter d'autres niveaux de threads applicatifs, mais ils ne peuvent pas interrompre ou stopper des tâches planifiées en cours. Un thread de haute priorité du noyau est destiné à l'exécution de l'ordonnanceur TinyOS. Pour la communication entre les threads de l'application et le noyau, TinyOS 2,1 fournit une interface. Lorsqu'un programme d'application fait un appel système, il n'est pas directement exécuté par le code. Au contraire, il affiche un message au thread noyau en publiant une tâche. Ensuite, le thread noyau exécute ou stoppe un processus planifié en cours Ce mécanisme garantit que seul le noyau exécute directement le code TinyOS. Les appels système, comme "create, destroy, pause, resume et join" sont fournis par le TOS threading library.

Protocole de communication 
La bibliothèque TinyOS comprend les protocoles réseaux, les services de distribution, les drivers pour capteurs et les outils d'acquisition de données. TinyOS est en grande partie écrit en C mais on peut très facilement créer des applications personnalisées en langages C, NesC, et Java.

Contiki 

Contiki (Dunkels et al., 2004; Dunkels et al., 2006) est un système configurable modulaire pour réseaux de capteurs. Contiki est organise en modules, une architecture plate. Un cœur non-reconfigurable permet de télécharger les modules applications ou sous-systèmes, qui constituent alors l’unité de reconfiguration dans Contiki. Un modèle d'exécution événementiel permet une implémentation efficace d’un état stable pour les modules.

Contiki est un système d'exploitation conçu pour prendre le moins de place possible, avec une faible empreinte mémoire. Pour cela, le code est écrit en C.
Ainsi, le système complet est supposé pouvoir tourner sans problèmes avec 2 ko de RAM et 40 ko de ROM.
Contiki possède une gestion de la programmation parallèle sous forme de « proto-threads », qui sont des processus légers développés spécialement pour l'occasion de même que µIPv6 permet d’être compatible IPV6.

Dans Contiki il existe une bibliothèque spécifique MEMB() contenue dans le noyau pour gérer la mémoire par block et réorganiser l'espace mémoire libre, cette gestion dynamique, permet d'optimiser la consommation énergétique.
Contiki fournit une implémentation RPL, appelée ContikiRPL, qui utilise IPv6 utilisant le protocole de routage RPL qui augmente la durée de vie des batteries des capteurs et permet de fonctionner sur des liens sans fil de faible puissance et des liens avec perte de puissance en ligne.

Mantis 

D’après le site officiel, Mantis OS est un système d’exploitation multithreads développé en C, langage choisi pour son efficacité et sa portabilité.
Mantis dispose d’un environnement de développement Linux et Windows. Il peut être déployé sur de nombreuses plateformes, tels que MICA2, MICAz, et TELOS. Son empreinte mémoire est faible : 500 octets en RAM et 14 ko en flash.
Mantis, apparu en 2005, a été conçu par l’université du Colorado avec comme objectif d’offrir un système d’exploitation multi threading. C’est un système modulaire dont le noyau supporte également les entrées/sorties synchrones, et un ensemble de primitives de concurrence.
L’économie d’énergie est réalisée par Mantis par une fonction de veille (sleep function) qui inactive le capteur lorsque tous les threads actifs sont terminés.
Mantis est un système dynamique, les modifications applicatives peuvent être réalisées en fonctionnement. Mantis apporte une compatibilité avec le modèle événementiel TinyOS à travers TinyMOS (MOS est la contraction de MantisOS), dont son noyau est équipé. Comme la plupart des systèmes d’exploitation pour capteurs, Mantis dispose d’une pile réseau, regroupée dans la couche COMM. La communication est  basée sur le principe de messages pondérés Active Message (AM). La couche COMM est dotée du protocole MAC, qui rend le réseau compatible avec de nombreux périphériques, de la gestion de mémoire tampon des paquets et de fonctions de synchronisation.
Concernant le débogage à distance, Mantis met en œuvre NodeMD, un système de déploiement et de notifications de défauts.

MantisOS est composé de 4 couches :
Couche 0 : Matériel
Couche 1 : Noyau/Ordonnanceur, communication (couche MAC et couche physique) pilotes de périphériques
Couche 2 : API Système Mantis
Couche 3 : Pile réseau, Serveur de commandes, Threads utilisateur

Nano-RK 
Nano-RK est un système d'exploitation temps réel multitâche préemptif pour capteurs en réseau. Il supporte le multi-hop reseau. Il possède une faible empreinte mémoire, Nano-RK uitlise 2 kb de RAM et 18kb de ROM.
Nano-RK fournit des APIs pour la gestion d’énergie des capteurs, notamment les fonctions suivantes : 
 query_energie() : renvoi une information sur le niveau d’énergie de la batterie.
 set_energy_mode() : permet de paramétrer le mode veille.
 get_energy_mode() : permet d'obtenir le paramétrage mode veille.
 tx_power_set() : permet de modifier le niveau de puissance radio du capteur.
 powerdown() : permet de mettre le capteur en veille pendant t secondes.

LiteOS 

LiteOS fournit un environnement comparable à UNIX, adapté aux capteurs en réseau. LiteOS possède un système de gestion des fichiers et des commandes en mode terminal distante semblable au commandes unix pour gérer les capteurs. Le noyau supporte le chargement dynamique et l’exécution multitâche d'applications. Un langage de programmation orienté objet C++ est disponible pour développer des programmes et permettre leur déploiement sur les capteurs. La version 1.0 de LiteOS supporte la plateforme Crossbow IRIS. Il fournit également un mécanisme de virtualisation de l’énergie et un système de débogage à distance.
LiteOS Possède une faible empreinte mémoire peut fonctionner avec 128Ko de mémoire flash et 4ko de RAM. LiteOS, fonctionne également sous RISC-V, notamment, avec l'aide des kits de développement de Huawei compilant avec GCC.

Taxonomie des systèmes existants 
Les systèmes sont classés selon les caractéristiques suivantes :

Statique / Dynamique.

Dans un système statique le programmeur doit allouer toutes les ressources lors de la conception. Par-contre, dans un système dynamique le programmeur alloue les ressources lors de l'exécution. Les systèmes dynamiques sont plus souples, et sont plus adaptés aux environnements à évolution dynamique. Cependant, ils ne sont pas fiables et une application boguée peut facilement entraîner le blocage du système.

Event-driven / Multi-threaded

Un système "Event-driven" est en dormance et réagit à l'arrivée d'un évènement. Un système "Multi-Threads" est un système qui accomplit les tâches en parallèle.

Monolithique / Modulaire

Un système est monolithique lorsque le système d'exploitation et l'application sont compilés en un seul bloc. À l'opposé, un système est modulaire si l’application est séparé du système d'exploitation. Dans ce cas le système d'exploitation est contenu dans un noyau.

Réseau

Par conception un capteur dispose d'une couche applicative réseau. TCP/IP est la norme.
protocoles réseau utilisés : µIP, µIPv6, RIMEEmbedded Systems/Atmel AVR/Operating systems and task managers, Active Message, Three-layer architecture.

Temps Réel

Le capteur peut être doté d'une synchronisation de référence en fonction des besoins applicatifs.

Langage

Le système d'exploitation peut être codé dans différents langage : nesC, LiteC++, C, C++, java

Système de fichiers

Reprogrammation

Le capteur est susceptible d'être reprogrammé à distance, en fonction de l'évolution de l'application.

Dépannage à distance

Le capteur doit pouvoir être analysé à distance, ou au minimum être capable de remonter des informations sur son état au gestionnaire du réseau.

Axes de recherches et évolution des systèmes d'exploitation 
 Axes de recherches
Beaucoup de recherche ont déjà été faites sur les systèmes d’exploitation pour capteur en réseau et ce domaine de recherche reste actif. Selon son historique, c’est un secteur de recherche relativement nouveau, les besoins d’application WSN grandissent et les possibilités de domaines d’application pour WSN n’ont pas toutes été explorées. De plus, l’évolution matérielle mènera à de nouvelles classes de capteurs avec une amélioration des capacités de communication, des plates-formes de capteur (la mémoire, le stockage, la puissance du processeur, etc.). Selon ces informations, il est possible de dégager les axes de recherche suivants afin de parvenir à un système d’exploitation pour réseau de capteur mature et moderne.

 Supporter les applications en temps réel  Il y a beaucoup de secteurs d'application pour WSN demandant du temps réel, par exemple, dans l'automatisation industrielle, le contrôle de processus chimique et le traitement de données multimédia et de transmission. Les ordonnanceurs de quelques systèmes d'exploitation ont été conçus pour supporter des opérations en temps réel aussi bien logicielles que matérielles, mais l'effort est loin d'être complet. Dans l'avenir, il y a un besoin de prévoir les algorithmes qui peuvent satisfaire les besoins les deux types de temps réel, logiciel et matériel. En outre, avec l'apparition de WMSN, une nouvelle pile de protocoles réseaux est exigée, elle permettra la mise en œuvre des protocoles et supportera des services différenciés.

 Gérer une mémoire auxiliaire  Les applications requièrent de plus en plus de mémoire. Par exemple, une application de bases de données typique exige une mémoire auxiliaire embarquée avec des nœuds de capteur.  peu d'OS fournissent un gestionnaire de fichiers pour gérer la mémoire auxiliaire.

 Supporter la mémoire virtuelle  Un nœud de capteur est très limité en mémoire vive et les applications en exigent de plus en plus. Il est donc nécessaire d’étudier des concepts de mémoire virtuelle dans des OS pour capteurs en réseau. Il faudra inventer les techniques de gestion de mémoire virtuelle qui seront efficaces en consommation d’énergie et de mémoire.

 Gérer et sécuriser la mémoire  Peu de travail a été fait sur la gestion de la mémoire pour des OS WSN. La raison principale est du fait qu'il a été assumé que seulement une application fonctionne sur un système d'exploitation WSN. Dans beaucoup d'OS contemporains, comme TinyOS et Contiki, l'application et le noyau compilent ensemble, partageant ainsi le même espace d'adressage. Cela peut être problématique, donc un système d'exploitation comme LiteOS fournit des espaces d'adressage séparés pour des applications différentes et le noyau. De telles techniques doivent mûrir afin de supporter une multitude d'applications simultanées sur des nœuds de capteur.

 Supporter de multiples applications  Des OS récents pour WSNS ont été développés en prenant en considération que seulement une application fonctionnera sur le capteur. Mais avec le développement de nouveaux secteurs d'application de réseaux de capteur cette supposition de base est mise en doute. Par exemple, avec le cas de WMSN, dans lequel les capteurs sont équipées de capteurs vocaux (des microphones), des capteurs vidéo comme des appareils photo(des caméras) et des capteurs scalaires. De là sur un seul nœud de capteur il est possible d’avoir une application qui utilise le capteur vidéo, c'est-à-dire, enregistrant la vidéo, faisant du traitement d’image dessus et envoie la vidéo compressée à la station de base. De même nous pouvons avoir d'autres applications qui se servent de capteurs de voix et des capteurs scalaires. Donc, les OS doivent satisfaire des applications multiples en même temps.

 Gérer une pile de protocoles de communication robuste  Un axe de recherche qui conçoit et implémente un protocole de couche croisé approprié pour des réseaux de capteur. La conception de protocole doit considérer des contraintes de nœuds de capteur aussi bien que de nouveaux secteurs émergents d'application pour des réseaux de capteur.

 Sécuriser  Le déploiement de WSNS dans le champ de bataille exige des fonctionnalités de sécurité rigoureuses, donc les OS pour WSN devraient fournir des mécanismes pour qu'un utilisateur de la station de base puisse authentifier des nœuds valides dans le réseau. De même en cas de demandes ou de mises à jour, les nœuds doivent pouvoir authentifier son origine.

 Gérer un système de gestion de données  Un nœud de capteur doit pouvoir stocker des données et comprendre le langage de requête. Un effort de recherche est exigé pour concevoir un système de gestion de données pour les nœuds de capteur.

 Localiser et supporter des API de synchronisation d'horloge  Pour répondre aux besoins d'application-spécifiques concernant la synchronisation de temps un axe de recherche concernant les OS est de fournir des API appropriées aux développeurs afin de concevoir leur propre protocole.

 API pour signal et traitement d'image  Dans le domaine du traitement d'image, les applications qui apparaissent nécessitent de la part de l’OS de fournir un jeu riche d'image de base et des API de traitement d’image ou de signal facilitant le travail du développeur.

 Evolution des systèmes d'exploitation
 Contiki  La version 2.3 apparaît en . Le développement de Contiki reste actif, puisque de nombreuses améliorations apparaissent avec cette nouvelle version. La première mise en avant est la pile µIPv6, annoncée en octobre dernier conjointement par Cisco, Atmel et l'équipe de Contiki, mais fraîchement intégrée au système. Contiki fait donc enfin partie des systèmes dits "IPv6 ready".

 LiteOS  La version 2.1 apparaît en . Il fournit un mécanisme de virtualisation de l'énergie (Virtual Batterie) et un débogueur (Declarative Tracepoints).

Applications

Catégories d’applications 

La classification des applications dépend du but pour lequel les capteurs en réseau sont utilisés. Selon Adi Mallikarjuna, ils peuvent être classés dans les catégories suivantes : (i) Contrôle, (ii) Détection/Classification/Dépistage et (iii) Direction. Ces applications sont utilisées dans des domaines différents, tels que :
 Environnemental  Ce domaine d'applications (Observatoire de l'environnement) peut se répartir entre des opérations de contrôle intérieures et extérieures.
Des applications de contrôle intérieures incluent typiquement le contrôle de bâtiments et des bureaux. (Exemple : le contrôle de la température ambiante, de la lumière, de l'air conditionné, de la qualité de l'air). D'autres applications intérieures importantes sont la détection de fumée et de feu. La recherche en génie civil a montré que les capteurs en réseau peuvent aussi être utilisés afin de contrôler les structures civiles comme les ponts et les bâtiments contre les méfaits des vibrations.
Les applications extérieures intéressantes de capteurs en réseau sont la détection de la dangerosité chimique, la surveillance des autoroutes, la prévision de tremblement de terre, d'éruption, de phénomène météorologique, la surveillance des rivières, la prévision d'inondation. Les capteurs en réseau sont aussi présents dans l'agriculture. Ils peuvent être utilisés pour anticiper les premières gelées, prévoir les conditions climatiques, améliorer la gestion des cultures et réduire des coûts. Le contrôle de l'humidité du sol est encore une application des capteurs en réseau dans l'agriculture.
 Santé  Ce domaine d'applications concerne typiquement la surveillance de patients et l'alerte de médecins. Les capteurs mesurent les actions récentes des patients et informent les médecins du comportement du patient. Une autre application pourrait être le traçage de l'utilisation des médicaments par les patients et les médecins dans les hôpitaux. Cet articledonne une vue d'ensemble des applications potentielles de capteur en réseau dans les services médicaux.
 Armée  Les nœuds de capteur conviennent bien au besoin d'applications militaires. Notamment pour la collecte d'information, le dépistage d'ennemi, la surveillance de champ de bataille, le repérage de cible, la sécurité de périmètre, la surveillance de frontière. Le projet majeur dans ce domaine est ExScal. L'un des premiers usages des capteurs sans fils fût militaire, à l'occasion de la guerre du Vietnam. Il s'agit de l'Opération Igloo White, qui en 1969, a permis de transmettre des renseignements via des ondes hertziennes depuis des capteurs placés le long d'une piste d'atterrissage.
 Industrie  La productivité, la réduction de coût et la sécurité sont cruciaux pour n'importe quelle industrie. Ces trois éléments nécessitent un contrôle complet et le contrôle de processus et d’équipements industriels. MachineTalker est un exemple de contrôle du niveau de liquide dans des réservoirs à carburant multiple dans le raffinage de pétrole et des installations de stockage. WiSA est un projet universitaire qui s'est concentré sur le contrôle des fonctions d'un cycle de production afin d’améliorer la performance en réduisant leur maintenance. Les articles suivants de 2006 et de 2009 évoquent des applications de capteurs en réseau dans des applications industrielles automatisées. General Electric (GE) utilise WSN pour contrôler leur équipement industriel.

Caractéristiques d'applications 
 

Les différentes catégories d'applications utilisées dans les domaines différents mentionnés ci-dessus montrent beaucoup de caractéristiques. Ils indiquent aussi quels types de logiciel de base sous-jacente seraient nécessaire pour satisfaire ces caractéristiques. Les caractéristiques ou besoins importants de ces applications sont récapitulées ci-dessous : 
 La plupart des applications exigent des garanties en temps réel sur les données. C'est particulièrement vrai dans le cas de la santé et des applications militaires. (Temps réel)
 La plupart des applications de WSN pourraient durer pendant des jours et les besoins des applications peuvent changer durant cette durée. L'environnement d'exécution devrait permettre de reconfigurer l'application pendant son exécution en changeant son code. (Reprogrammation)
 Les applications de contrôle sont destinées à s’exécuter pendant une plus longue période de temps. La disponibilité de la source d’énergie est essentielle surtout s’il est difficile de remplacer la batterie comme lorsque les WSNs sont déployés dans des terrains inaccessibles et des déserts. Il est obligatoire au niveau du système d'exploitation de conserver l'utilisation de la puissance pour les moments appropriés. (Gestion de la consommation d'énergie)
 Puisque ces applications fonctionnent sur des centaines ou des milliers de nœuds de capteur, l'environnement d'exécution devrait être capable de s’adapter au nombre de nœuds sans dégrader la performance des applications. (Adaptabilité)

Ces caractéristiques d’applications sont évaluées selon les catégories d'applications dans le tableau suivant. (x) indique non requis et (v) indique requis. Le tableau montre aussi l'OS qui peut être utilisé dans chaque catégorie d'applications.

Les caractéristiques montrées dans le tableau récapitulatif influences les fonctionnalités du système d'exploitation. L'architecture et la gestion de la mémoire du système d'exploitation permettent la fonction de reprogrammation. Le modèle d'exécution et le mécanisme de planification permettent à la propriété de temps réel d'être garantie.

Perspectives d'applications 
Dans la plupart des plates-formes matérielles, la transmission radio est la source principale de consommation d’énergie et l’activité radio est en grande partie commandée par la couche MAC. En ce qui concerne le protocole MAC, les sources principales de perte d’énergie sont les collisions, l’écoute (idle listening) pour recevoir des données possibles, overhearing i.e. recevant
des données destinées à d’autres nœuds, le contrôle de l’overhead et over-emitting i.e. la transmission d’un message quand le destinataire n’est pas prêt. Donc, pour économiser au mieux l’énergie de la batterie d’un capteur, il faudrait que les transmetteurs radio soient éteints le plus possible. Cependant, ceci pourrait poser le problème de la synchronisation des capteurs et la répartition des périodes de réveil. Ainsi, il faudrait que la couche MAC permette aux capteurs d’avoir des périodes de sommeil assez longues, mais sans perturber les communications.
Les protocoles de routages pour acheminer les données ont un impact sur la consommation d’énergie des capteurs, d’où l'importance d’établir des algorithmes pour optimiser la consommation d'énergie des capteurs lorsqu'ils transmettent des données ou restent à l'écoute du réseau. Les capteurs communiquent entre eux de proche en proche pour retransmettre l'information à la station de base de l'environnement surveillé. Pour cela les capteurs se mettent à l’écoute inactive de leur voisinage, c'est-à-dire qu'il restent à l’écoute pour recevoir du trafic sans en envoyer et cela parfois sur une longue période de temps avant qu'un événement ne soit détecté par le capteur. C'est ce gaspillage d’énergie que S-MAC permet de résoudre. De plus, il permet de limiter les collisions sur le réseau et ainsi de réduire les réémissions gourmandes en énergie. S-MAC utilise un schéma d’écoute périodique et de sommeil. Ainsi les capteurs, sont au ralenti pendant un certain temps si aucun cas de détection ne survient. Compte tenu du fait que le débit de données pendant cette période est très faible, il n'est pas nécessaire de rester à l'écoute des nœuds tout le temps. S-MAC permet ainsi d'atteindre près de 50 % d'économies d'énergie.
DSMAC (S-MAC dynamique) est une autre variante de S-MAC. Ce protocole ajoute un cycle dynamique d’activité à S-MAC, qui réduit la latence dans les applications critiques. Par exemple, un nœud peut doubler son cycle d’activité si le niveau de sa batterie est au-dessus d’un certain seuil. DSMAC génère une latence inférieure à celle de S-MAC avec une meilleure
moyenne de consommation d’énergie par paquet.

L'axe de recherche sur les nouveaux systèmes d'exploitation pour capteur s'oriente vers l'optimisation des protocoles de routage, fonctionnalité incluse dans le noyau des systèmes d'exploitation.

Un autre axe de recherche consiste à introduire dans le noyau des systèmes d'exploitation des protocoles de communication dotés de  fonctions GPS comme le protocole ZigBee.

Wireless Multimedia Sensor Networks étend les capacités multimédia de capteur en réseau, en fournissant aux applications des domaines environnementaux, militaires, de la santé et industriels des applicatifs  multimédias comme la vidéo ou le son.

Notes et références

Notes

Références

Bibliographie

Livres

Articles scientifiques

Autres documents

Thèses

Liens externes