Système d'exploitation pour capteur en réseau

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.

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[23].

Caractéristiques d'un système d'exploitation pour capteur

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[23].

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[23].

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[23].

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[23].

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é[24]. La survenue d’un évènement par nature est asynchrone[24]. Les tâches de gestion courante peuvent être interrompues par la survenue d’un évènement, mais pas l’inverse[24].

Multi Thread[note 4] (Thread-based)

Un thread est un élément de calcul de base. Il a son propre état[24]. Le modèle mulri-thread donne de la flexibilité dans l'écriture d'applications[24]. Une application consiste en l’exécution d’un ensemble de threads^{[réf. nécessaire]}. Les tâches dévolues au réseau ou à l’ordonnanceur sont également des threads[24]. 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)[24].

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.

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[25]. 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 [26]^,[27].

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[16]. Il existe deux catégories d'ordonnancement des taches[28] :

• 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[29].

• l'ordonnancement en temps partagé

L'ordonnancement des tâches en mode événementiel, convient pour des évènements asynchrones.

• 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)

Les nœuds sont par définition alimentés par une batterie[30]. 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[27], 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[31] 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[31], 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[31] 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[32]. 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é[33]. Plusieurs protocoles dérivés du protocole MAC comme (S-MAC[34], B-MAC[35], X-MAC[36]), 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[37].

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[37].

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 [37].

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 [46]. (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[47] (Jeong et al., 2003) permet de télécharger et réinstaller une nouvelle image système en effectuant un redémarrage. FlexCup[48] (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[19]. TinyOS[4] a une empreinte mémoire de 4Ko[49]. 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[50]. L'utilisation du langage nesC permet d'optimiser le code et ainsi réduire l'usage de la RAM[27]. 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[28]. Les principaux systèmes embarqués candidats pour être utilisés par les capteurs sont TinyOS et Contiki[19]. 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é[28]. Maté[51] (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.

TinyOS s'inscrit dans la catégorie des architectures monolithiques[52]. 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[19]. 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[53].

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[41].

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[54].

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[52]^,[55].

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[56]. Contiki fournit une implémentation RPL[note 5], appelée ContikiRPL[57], 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[58].

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[59]. 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[19]. 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[52]. Concernant le débogage à distance, Mantis met en œuvre NodeMD, un système de déploiement et de notifications de défauts[60].

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 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[61]. Nano-RK fournit des APIs[62] 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 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[63]. LiteOS Possède une faible empreinte mémoire peut fonctionner avec 128Ko de mémoire flash et 4ko de RAM[64]. LiteOS, fonctionne également sous RISC-V, notamment, avec l'aide des kits de développement de Huawei compilant avec GCC[65].

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[66].

• 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[67].

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[68], 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[67].

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. Actuellement peu d'OS fournissent un gestionnaire de fichiers pour gérer la mémoire auxiliaire[67].

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[67].

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[67].

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[67].

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[67].

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[67].

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[67].

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[67].

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[67].

• Evolution des systèmes d'exploitation

Contiki

La version 2.3 apparaît en juin 2011. 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"[69].

LiteOS

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

La classification des applications dépend du but pour lequel les capteurs en réseau sont utilisés[71]. 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[72].

• 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[71].
• 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[71].

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[71]. Cet article[73]donne 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[71]. Le projet majeur dans ce domaine est ExScal[74]. 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[75].

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[71]. MachineTalker[76] 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[77] 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[78] et de 2009[79] é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[80].

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[71]. (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[71]. (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[71]. (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[71]. (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[71].

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[25]. 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[25]. 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[81].

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[82].

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[83].

Wireless Multimedia Sensor Networks[68] é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[84].

• (en) Avi Silberschatz et Peter Galvin, « OPERATING SYSTEM CONCEPTS », Department of Computer Sciences University of Texas at Austin,‎ 1994 (lire en ligne)

• (en) Ivan Lee, William Shaw et Xiaoming Fan, « Chapter 22 : Wireless Multimedia Sensor Networks », Guide to Wireless Sensor Networks Computer Communications and Networks,‎ 2009, p. 561-582 (DOI 10.1007/978-1-84882-218-4_22, lire en ligne)

• Andrew Tanenbaum, Systèmes d’exploitation, Pearson, 2008, 3^e éd. [détail de l’édition]

• Edsger Dijkstra, « The structure of the 'THE'-multiprogramming system », Communications of the ACM, vol. 11, n^o 5,‎ 1968, p. 341–346 (DOI 10.1145/363095.363143)

• (en) Huali Chen et Zhifan Feng, « Design of Data Acquisition and Record System Based on ZigBee and GPS », European workshop on wireless sensor networks.,‎ décembre 2008, p. 682-686 (ISBN 978-0-7695-3490-9, DOI 10.1109/PACIIA.2008.148, lire en ligne)

• (en) Bambang Harjito et Song Hang, « Wireless Multimedia Sensor Networks Applications and Security Challenges », Broadband, Wireless Computing, Communication and Applications (BWCCA), 2010 International Conference on,‎ novembre 2010, p. 842 - 846 (ISBN 978-1-4244-8448-5, DOI 10.1109/BWCCA.2010.182, lire en ligne)

• (en) Peng Lin, Chunming Qiao et Xin Wang, « Medium access control with a dynamic duty cycle for sensor networks », TinyOS documentation.,‎ mars 2004, p. 1534-1539 (ISBN 0-7803-8344-3, DOI 10.1109/WCNC.2004.1311671, lire en ligne)

• (en) Philip Levis et David Culler, « Maté: a tiny virtual machine for sensor networks », European workshop on wireless sensor networks.,‎ octobre 2002 (ISBN 1-58113-574-2, DOI 10.1145/605397.605407, lire en ligne)

• (en) MARRON,, GAUGER, LACHENMANN, MINDER, SAUKH et ROTHERMEL, « FlexCup : A Flexible and Efficient Code Update Mechanism for Sensor Networks », European workshop on wireless sensor networks.,‎ 2006, p. 212-227 (lire en ligne)

• (en) Jaein Jeong, Sukun Kim et Alan Broad, « Network reprogramming », TinyOS documentation.,‎ aout 2003 (lire en ligne)

• (en) David Gay, Philip Levis, Robert von Behren, Matt Welsh, Eric Brewer et David Culler, « The nesC Language : A Holistic Approach to Networked Embedded Systems », PLDI’03, June 9–11, 2003, San Diego, California, USA.,‎ juin 2003 (lire en ligne)

• (en) Jason Hill, Robert Szewczyk, Alec Woo, Seth Hollar, David Culler et Kristofer Pister, « System Architecture Directions for Networked Sensors », Department of Electrical Engineering and Computer Sciences University of California, Berkeley Berkeley, CA,‎ 2000 (lire en ligne)

• (en) Nicolas Tsiftes, Joakim Eriksson et Adam Dunkels, « Low-Power Wireless Ipv6 Routing with ContikiRPL », Swedish Institute of Computer Science Kista, Sweden,‎ avril 2010, p. 1-2 (lire en ligne)

• (en) P. Levis, S. Madden, J. Polastre, R. Szewczyk, K. Whitehouse, A. Woo, D. Gay, J. Hill, M. Welsh, E. Brewer et D. Culler, « TinyOS: An Operating System for Sensor Networks », Ambient Intelligence,‎ 2005 (DOI 10.1007/3-540-27139-2_7, lire en ligne)

• (en) Muhammad Omer Farooq et Thomas Kunz, « Operating Systems for Wireless Sensor Networks: A Survey », Department of Systems and Computer Engineering, Carleton University Ottawa, Canada,‎ mai 2011, p. 5900-5930 (DOI 10.3390/s110605900, lire en ligne)

• (en) Muhammad Omer Farooq, Sadia Aziz et Abdul Basit Dogar, « State of the Art in Wireless Sensor Networks Operating Systems: A Survey », T.-h. Kim et al. (Eds.): FGIT 2010, LNCS 6485, pp. 616–631, 2010.© Springer-Verlag Berlin Heidelberg 2010,‎ 2010, p. 616-631 (DOI 10.1007/978-3-642-17569-5_61, lire en ligne)

• (en) Qing Cao, Liqian Luo, John Stankovic, Yusuf Sarwar et Tarek Abdelzaher, « Declarative Tracepoints: A Programmable and Application Independent Debugging System for Wireless Sensor Networks », Department of Computer Science University of Illinois,‎ novembre 2008 (lire en ligne)

• (en) Sujesha Sudevalayam et Purushottam Kulkarni, « Energy Harvesting Sensor Nodes: Survey and Implications », IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 13, NO. 3, THIRD QUARTER 2011,‎ septembre 2011, p. 443 - 461 (DOI 10.1109/SURV.2011.060710.00094, lire en ligne)

• (en) Qing Cao, Debessay Fesehaye, Nam Pham, Yusuf Sarwar et Tarek Abdelzaher, « Virtual Battery:An Energy Reserve Abstraction for Embedded Sensor Networks », Department of Computer Science University of Illinois at Urbana-Champaign,‎ décembre 2008, p. 123 - 133 (ISBN 978-0-7695-3477-0, DOI 10.1109/RTSS.2008.41, lire en ligne)

• (en) Shah Bhatti, James Carlson, Hui Dai, Jing Deng, Jeff Rose, Anmol Sheth, Brian Shucker, Charles Gruenwald, Adam Torgerson et Richard Han, « MANTIS OS: An Embedded Multithreaded Operating System for Wireless Micro Sensor Platforms », University of Colorado at Boulder Computer Science Department Boulder, CO, 80309,‎ aout 2005 (lire en ligne)

• (en) Anthony D. Joseph, « Operating Systems and Systems Programming Course Reader for Spring 2008 », University of California Berkeley Computer Science 162,‎ juin 2008 (ISBN 0-7695-2260-2, lire en ligne)

• (en) Adam Dunkels, Bjorn Gronvall et Thiemo Voigt, « Contiki - a Lightweight and Flexible Operating System for Tiny Networked Sensors », Local Computer Networks, 2004. 29th Annual IEEE International Conference on,‎ novembre 2004, p. 455-462 (ISBN 0-7695-2260-2, DOI 10.1109/LCN.2004.38, lire en ligne)

• (en) Nicolas Tsiftes, Joakim Eriksson, Finne Finne, Fredrik Österlind, Joel Höglund et Adam Dunkels, « A Framework for Low-Power IPv6 Routing Simulation, Experimentation, and Evaluation », Swedish Institute of Computer Science,‎ septembre 2010 (lire en ligne)

• (en) Joseph Polastre, Robert Szewczyk et David Culler, « Telos: Enabling Ultra-Low Power Wireless Research », Computer Science Department University of California, Berkeley Berkeley, CA 94720,‎ avril 2005, p. 364-369 (ISBN 0-7803-9201-9, DOI 10.1109/IPSN.2005.1440950, lire en ligne)

• (en) Giuseppe Anastasi, Marco Conti, Andrea Passarella et Luciana Pelusi, « Mobile-relay Forwarding in Opportunistic Networks », Dept. of Information Engineering University of Pisa, Italy. IIT-CNR National Research Council, Italy,‎ mai 2008 (lire en ligne)

• (en) Jonathan W. Hui et David Culler, « The dynamic behavior of a data dissemination protocol for network programming at scale », Proceeding SenSys '04 Proceedings of the 2nd international conference on Embedded networked sensor systems,‎ 2004 (ISBN 1-58113-879-2, DOI 10.1145/1031495.1031506, lire en ligne)

• (en) Jason Hill, Robert Szewczyk, Alec Woo, Seth Hollar, David Culler et Kristofer Pister, « System Architecture Directions for Networked Sensors », Department of Electrical Engineering and Computer Sciences University of California, Berkeley Berkeley, CA,‎ mai 2000, p. 93-104 (lire en ligne)

• (en) Adi Mallikarjuna, Reddy V Avu, Phani Kumar, D Janakiram et G Ashok Kumar, « Operating Systems for Wireless Sensor Networks: A Survey Technical Report », Distributed and Object Systems Lab Department of Computer Science and Engineering Indian Institute of Technology Madras, Chennai, India - 600036,‎ mai 2007 (lire en ligne)

• (en) Qiang Wang, Yaoyao Zhu, Liang Cheng et Lehigh University, « Reprogramming wireless sensor networks: challenges and approaches », Dept. of Comput. Sci. & Eng., Lehigh Univ., Bethlehem, PA, USA,‎ juin 2006, p. 48 - 55 (DOI 10.1109/MNET.2006.1637932, lire en ligne)

• (en) Wei Dong, Chun Chen, Xue Liu et Jiajun Bu, « Providing OS Support for Wireless Sensor Networks: Challenges and Approaches », IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 12, NO. 4, FOURTH QUARTER 2010,‎ mai 2010, p. 519 - 530 (DOI 10.1109/SURV.2010.032610.00045, lire en ligne)

• (en) Jialiang Wang, Hai Zhao, Peng Li, Zheng Liu, Jie Zhao et Wei Gao, « The Mechanism and Performance Comparison of Two Wireless Sensor Network Operating System Kernels », Information Technology: New Generations, 2009. ITNG '09. Sixth International Conference on,‎ avril 2009, p. 1442 - 1446 (ISBN 978-1-4244-3770-2, lire en ligne)

• (en) Kim Nakyoung, Choi Sukwon et Hojung Cha, « Automated sensor-specific power management for wireless sensor networks », Mobile Ad Hoc and Sensor Systems, 2008. MASS 2008. 5th IEEE International Conference on,‎ octobre 2008, p. 305 - 314 (ISBN 978-1-4244-2574-7, lire en ligne)

• (en) Seungmin Park, Jin Won Kim, Kwangyong Lee, Kee-Young Shin et Daeyoung Kim, « Embedded sensor networked operating system », Object and Component-Oriented Real-Time Distributed Computing, 2006. ISORC 2006. Ninth IEEE International Symposium on,‎ mai 2006, p. 305-314 (ISBN 0-7695-2561-X, DOI 10.1109/ISORC.2006.33)

• (en) Kim Nakyoung, Choi Sukwon et Hojung Cha, « Automated sensor-specific power management for wireless sensor networks », Mobile Ad Hoc and Sensor Systems, 2008. MASS 2008. 5th IEEE International Conference on,‎ octobre 2008, p. 305 - 314 (ISBN 978-1-4244-2574-7, lire en ligne)

• (en) Anand Eswaran, Anthony Rowe et Raj Rajkumar, « Nano-RK: an Energy-aware Resource-centric RTOS for Sensor Networks », Real-Time and Multimedia Systems Lab. Electrical and Computer Engineering Department, {aeswaran,agr,raj}@ece.cmu.edu. School of Computer Science Carnegie Mellon University, Pittsburgh, PA, USA,‎ novembre 2009 (lire en ligne)

• (en) Anthony Rowe, Rahul Mangharam et Raj Rajkumar, « FireFly: A Time Synchronized Real-Time Sensor Networking Platform. », Department of Electrical and Computer Engineering Carnegie Mellon University, Pittsburgh, PA, USA {agr, rahulm, raj}ece.cmu.edu,‎ août 2007 (lire en ligne)

• (en) Kang Lee, « IEEE P1451 Draft Standard for a Smart Transducer Interface for Sensors and Actuators », IEEE,‎ septembre 1993 (lire en ligne)

• (en) Kang Lee, « Brief Description of the Family of IEEE 1451 Standards », IEEE,‎ septembre 2009 (lire en ligne)

• (en) Michael Olson, Annie Liu, Matthew Faulkner et K. Mani Chandy, « Rapid Detection of Rare Geospatial Events: Earthquake Warning Applications », ACM New York, NY, USA,‎ novembre 2011 (ISBN 978-1-4503-0423-8, DOI 10.1145/2002259.2002276, lire en ligne)

• (en) G. Shobha, Ranjana R. Chittal et Kamod Kumar, « Medical Applications of Wireless Networks », IEEE,‎ septembre 2007, p. 82 - 82 (ISBN 0-7695-2938-0, DOI 10.1109/ICSNC.2007.51, lire en ligne)

• (en) A. Bonivento, L.P. Carloni et A. Sangiovanni-Vincentelli, « Platform-Based Design of Wireless Sensor Networks for Industrial Applications », IEEE,‎ juillet 2006, p. 1 - 6 (ISBN 3-9810801-1-4, DOI 10.1109/DATE.2006.243975, lire en ligne)

• (en) A. Arora, R. Ramnath, E. Erting et P. Sinha, « ExScal: elements of an extreme scale wireless sensor network », IEEE,‎ novembre 2005, p. 102-108 (ISBN 0-7695-2346-3, DOI 10.1109/RTCSA.2005.47, lire en ligne)

• (en) V.C. Gungor et G.P. Hancke, « Industrial Wireless Sensor Networks: Challenges, Design Principles, and Technical Approaches », IEEE,‎ septembre 2009, p. 4258 - 4265 (DOI 10.1109/TIE.2009.2015754, lire en ligne)

• (en) I.F. Akyildiz, W. Su, Y. Sankarasubramaniam et E. Cayirci, « Wireless sensor networks: a survey », Science Direct,‎ décembre 2001, p. 393–422 (DOI doi:10.1016/S1389-1286(01)00302-4, lire en ligne)

• (en) Ning Xu, « A Survey of Sensor Network Applications », IEEE Communications Magazine,‎ 2002, p. 1 - 9 (DOI 10.1.1.131.9647, lire en ligne)

• (en) Th. Arampatzis, J. Lygeros et S. Manesis, « A Survey of Applications of Wireless Sensors and Wireless Sensor Networks », IEEE,‎ mars 2006, p. 719 - 724 (ISBN 0-7803-8936-0, DOI 10.1109/.2005.1467103, lire en ligne)

• (en) Ye Wei, J. Heidemann et D. Estrin, « An energy-efficient MAC protocol for wireless sensor networks », INFOCOM 2002. Twenty-First Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE,‎ novembre 2002, p. 1567 - 1576 vol.3 (ISBN 0-7803-7476-2, DOI 10.1109/INFCOM.2002.1019408, lire en ligne)

• (en) K. Klues, V. Handziski, C. Lu, A. Wolisz, D. Gay et P. Levis, « Integrating concurrency control and energy management in device drivers », Proc. ACM SOSP,‎ décembre 2007, p. 251 - 263 (ISBN 978-1-59593-591-5, DOI 10.1145/1294261.1294286, lire en ligne)

• (en) Veljko Krunic, Erico Trumpler et Richard Han, « NodeMD: Diagnosing Node-Level Faults in Remote Wireless Sensor Systems », ACM,‎ juin 2007, p. 1 (ISBN 978-1-59593-614-1, lire en ligne)

• (en) Geoff V Merrett et Yen Kheng Tan, « Wireless Sensor Networks: Application-Centric Design », inTech,‎ décembre 2010, p. 1 - 492 (ISBN 978-953-307-321-7, lire en ligne)

• (en) Julian W. Gardner, Krishna C. Persaud, Perena Gouma et Ricardo Gutierrez-Osuna, « CALL FOR PAPERS IEEE Sensors Journal Special issue on Machine Olfaction », IEEE,‎ novembre 2011 (lire en ligne)

• (en) Daniela De Venuto, Weileun Fang et Jacob Abraham, « CALL FOR PAPERS IEEE Sensors Journal Special issue on Advances in Sensors and Interfaces », IEEE,‎ novembre 2011 (lire en ligne)

• (en) Aimé Lay-Ekuakille, Olfa Kanoun, Cristina Davis et Antonio Trabacca, « CALL FOR PAPERS IEEE Sensors Journal Special issue on Sensors for Non-Invasive Physiological Monitoring », IEEE,‎ novembre 2011 (lire en ligne)

• (en) John T. Correll, « Igloo White », Air Force Magazine,‎ novembre 2004 (lire en ligne)

• Lionel Barrère, Étude et proposition de services dans les réseaux mobiles militaires de type MANet, juillet 2009, 134 p. (lire en ligne)