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

Article principal : système embarqué.

Les systèmes d’exploitation pour capteur en réseau (notés également WSN[note 1]) 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[1], ERIKA Enterprise[2], Nano-RK[3], TinyOS[4], MantisOS[5], RETOS[6], Senses[7], Cormos[8], LiteOS[9], NanoQplus[10].

Contexte technologique[modifier | modifier le code]

Le capteur constitue la partie matérielle que doit gérer le système d’exploitation[11]. 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[12],[13].

Schéma d'architecture d'un capteur

Les éléments constitutifs du capteur sont les suivants[14] :

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 128 ko, alors que la taille de la mémoire flash atteint quelques Mo.

un transmetteur radio[note 2]
L'émetteur-récepteur assure 2 fonctions : transmettre des signaux (émetteur) et recevoir des signaux (récepteur).
  1. 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.
  2. 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[modifier | modifier le code]

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[note 3]), 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[15],[16].

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

Les systèmes d'exploitation pour réseau de capteurs sans fil tels que TinyOS[4], Contiki[1], SOS[18], MantisOS[5], Nano-RK[3],[19]sont 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[20]. Malgré ces limites matérielles, les capteurs doivent intégrer les fonctionnalités de base d'un système d’exploitation[21] telles que :

Ils doivent en plus gérer les spécificités propres aux systèmes d'exploitation pour capteur en réseau[21] :

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

Principes architecturaux[modifier | modifier le code]

Généralités[modifier | modifier le code]

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[modifier | modifier le code]

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

Modèle d’exécution[modifier | modifier le code]

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.

Reprogrammation[modifier | modifier le code]

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

Ordonnancement[modifier | modifier le code]

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] :

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 des tâches en mode événementiel, convient pour des évènements asynchrones.

Algorithmes d'ordonnancement[modifier | modifier le code]

Gestion de l'énergie[modifier | modifier le code]

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.

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

Historique[modifier | modifier le code]

TinyOS[4]
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[1]
Contiki, est un système développé et soutenu par l'Institut d'Informatique Suédoise. Adam Dunkels est l'initiateur du projet[38].
Mantis OS[5]
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[3]
RETOS[6]
RETOS est un système développé par l'Université Yonsei en Corée. La version 1.1.0 apparaît en .
LiteOS[9]
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[modifier | modifier le code]

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[19]. 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[39]. Enfin, deux autres articles, de 2010[40] et 2011[41], 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é[42] 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[modifier | modifier le code]

Apparus récemment[43](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[44](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[45].


TinyOS[modifier | modifier le code]

Article détaillé : 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[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.

Architecture[modifier | modifier le code]

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

Modèle de Programmation[modifier | modifier le code]

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

Protocole de communication[modifier | modifier le code]

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[modifier | modifier le code]

Article détaillé : 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[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].

Mantis[note 6][modifier | modifier le code]

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[modifier | modifier le code]

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[modifier | modifier le code]

Article détaillé : 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[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].

Taxonomie des systèmes existants[modifier | modifier le code]

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.

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


Taxonomie des systèmes d'exploitation pour capteur en réseau[63]
TinyOS Contiki SOS Mantis Nano-RK RETOS LiteOS
Publication (année) ASPLOS (2000) EmNets (2004) MobiSys (2005) MONET (2005) RTSS (2005) IPSN (2007) IPSN (2008)
Statique/Dynamique Statique Dynamique Dynamique Dynamique Statique Dynamique Dynamique
Événementiel/Thread Event&Thread (TinyThread, TOSThreads) Event&Threads&Protothreads Event Thread&Event (TinyMOS) Thread Thread Thread&Event (through callback)
Monolithique/Modulaire Monolithique Modulaire Modulaire Modulaire Monolithique Modulaire Modulaire
Réseau Message Actif uIP, uIPv6,Rime Message "comm" Socket Three-layer Architecture File-Assisted
Support Temps réel non non Non Non oui POSIX 103.1b non
Language Programmation nesC C C C C C LiteC++
File System Single level (&.x only) (ELF, Matchbox) Coffee non non (prévu pour la version 1.1) non Hierarchical Unix-like)
Reconfiguration oui (Deluge, FlexCup) oui oui (Modulaire) non (prévu pour la version 1.1) non oui oui
Débogage Distant oui(Clairvoyant) non non oui (NodeMD) non non oui (DT)

Axes de recherches et évolution des systèmes d'exploitation[modifier | modifier le code]

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[Quand ?] 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].


  • Évolution 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"[69].
LiteOS
La version 2.1 apparaît en . Il fournit un mécanisme de virtualisation de l'énergie[70] (Virtual Batterie) et un débogueur (Declarative Tracepoints[66]).

Applications[modifier | modifier le code]

Catégories d’applications[modifier | modifier le code]

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


Caractéristiques d'applications[modifier | modifier le code]

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.

Tableau récapitulatif des caractéristiques d’application et des systèmes d’exploitation appropriés[71]
Catégories Temps-réel Reprogrammation Gestion de la consommation d’énergie Adaptabilité Systèmes d’exploitation approprié
Environnemental
Intérieur x x x x Tous les systèmes d’exploitation
Extérieur x v v v SOS, Contiki, MantisOS, SenOS, DCOS, Nano-RK, t-kernel
Santé v x x x PEEROS, Nano-RK, DCOS, CORMOS
Armée v v v v Nano-RK, DCOS
Industrie v v v v Nano-RK, DCOS

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

Perspectives d'applications[modifier | modifier le code]

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

Notes et références[modifier | modifier le code]

Notes[modifier | modifier le code]

  1. ↑ Acronyme : Wireless Sensor Network, littéralement : Réseau de senseur sans fils.
  2. ↑ Le transmetteur assure en fait deux fonctions, émetteur ET récepteur, d'où l'usage plus courant du terme émetteur-récepteur pour lever l’ambiguïté du terme anglais "transmit" signifiant "émettre").
  3. ↑ Acronyme : Central Processing Unit.
  4. ↑ Thread : Thread, littéralement : fil (comme fil de coton). Dans le contexte informatique, thread n'est pas traduit, on utilise donc ce mot tel quel.
  5. ↑ RPL : Routing Protocol for Low power and Lossy Networks : norme IETF pour le routage IPv6 en faible puissance.
  6. ↑ Acronyme : MultimodAl system for NeTworks of In-situ, littéralement : Système multimodal pour les réseaux in-situ.

Références[modifier | modifier le code]

  1. ↑ a b et c Contiki
  2. ↑ ERIKA Enterprise
  3. ↑ a b et c Nano-RK
  4. ↑ a b c et d TinyOS
  5. ↑ a b et c MantisOS
  6. ↑ a et b RETOS
  7. ↑ Senses
  8. ↑ Cormos
  9. ↑ a et b LiteOS
  10. ↑ NanoQplus
  11. ↑ Joseph 2008, p. 8-12
  12. ↑ Anastasi 2008, p. 26-28
  13. ↑ Bhatti 2005, p. 1
  14. ↑ Mallikarjuna 2007, p. 2
  15. ↑ Farooq 2010, p. 617,
  16. ↑ a et b Farooq 2011, p. 5903
  17. ↑ Dong 2010, p. 519
  18. ↑ SimpleOS
  19. ↑ a b c d e et f Dong 2010, p. 521-522
  20. ↑ Dunkels 2004, p. 1-2
  21. ↑ a et b Silberschatz 1994, p. 3-4
  22. ↑ Dunkels 2010, pages 1-2
  23. ↑ a b c d et e Farooq 2011, p. 5902-5903
  24. ↑ a b c d e f et g Farooq 2011, p. 5902
  25. ↑ a b et c Wei 2002, p. 1-3
  26. ↑ Mallikarjuna 2007, p. 8
  27. ↑ a b et c Dong 2010, p. 524
  28. ↑ a b et c Dong 2010, p. 520
  29. ↑ Mallikarjuna 2007, p. 11
  30. ↑ Mallikarjuna 2007, p. 1
  31. ↑ a b et c Klues 2007
  32. ↑ Medium access control 2002, p. 416
  33. ↑ Medium access control 2002, p. 412-416
  34. ↑ S-MAC, p. 414
  35. ↑ B-MAC
  36. ↑ Michael Buettner, Gary Yee, Eric Anderson et Richard Han, « X-mac: A short preamble mac protocol for duty-cycled wireless sensor networks », sur citeseerx.ist.psu.edu, The Pennsylvania State University, (consulté le ).
  37. ↑ a b et c .Sudevalayam 2011, p. 443
  38. ↑ Adam Dunkels
  39. ↑ Mallikarjuna 2007, p. 17-20
  40. ↑ Farooq 2010, p. 5-10
  41. ↑ a et b Farooq 2011, p. 5905-5921
  42. ↑ Farooq 2010, p. 618
  43. ↑ Hill 2000, p. 1-2
  44. ↑ Bhatti 2005, p. 10
  45. ↑ Farooq 2010, p. 619
  46. ↑ Gay 2003, p. 2-4
  47. ↑ Jeong 2003, p. 3-7
  48. ↑ MARRON 2006, p. 1-4
  49. ↑ Lewis 2005, p. 125
  50. ↑ Farooq 2010, p. 616-617
  51. ↑ Levis 2002, p. 1-2
  52. ↑ a b et c DONG 2010, p. 523
  53. ↑ Farooq 2011, p. 5905-5906
  54. ↑ Farooq 2011, p. 5908-5909
  55. ↑ Farooq 2011, p. 5909
  56. ↑ Farooq 2010, p. 624
  57. ↑ Tsiftes 2010, p. 1-2
  58. ↑ Farooq 2010, p. 625
  59. ↑ Farooq 2011, p. 5913
  60. ↑ Krunic 2007, p. 1
  61. ↑ Farooq 2011, p. 5917
  62. ↑ Mallikarjuna 2007, p. 17
  63. ↑ a et b Dong 2010, p. 522
  64. ↑ Farooq 2011, p. 5921
  65. ↑ (en) Jean-Luc Aufranc, « Hi3861 based HiSpark WiFi IoT development board supports LiteOS and HarmonyOS », sur CNX-Software, .
  66. ↑ a et b Abdelzaher 2008, p. 6
  67. ↑ a b c d e f g h i j et k Farooq 2011, p. 5926-5929
  68. ↑ a et b Lee 2009, p. 561-582
  69. ↑ Contiki_v2.3 2011
  70. ↑ Cao 2008, p. 132
  71. ↑ a b c d e f g h i j k et l Mallikarjuna 2007, p. 20-23
  72. ↑ A Survey of Applications of Wireless Sensors and Wireless Sensor Networks 2006, p. 719-723
  73. ↑ Shobba 2007
  74. ↑ ExScal 2005
  75. ↑ Correl 2004
  76. ↑ MachineTalker
  77. ↑ WiSA
  78. ↑ WSN pour plateformes industrielles 2006
  79. ↑ WSN pour plateformes industrielles 2009
  80. ↑ GE
  81. ↑ Lin 2004, p. 1536-1537
  82. ↑ Wang 2009, p. 1-3
  83. ↑ Chen 2008, p. 1-3
  84. ↑ Harjito 2010, p. 842-846

Bibliographie[modifier | modifier le code]

Livres[modifier | modifier le code]

  • (en) Avi Silberschatz et Peter Galvin, « OPERATING SYSTEM CONCEPTS », Department of Computer Sciences University of Texas at Austin,‎ (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,‎ , p. 561-582 (DOI 10.1007/978-1-84882-218-4_22, lire en ligne)

Articles scientifiques[modifier | modifier le code]

  • (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,‎ , p. 842 - 846 (ISBN 978-1-4244-8448-5, DOI 10.1109/BWCCA.2010.182, 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.,‎ , p. 212-227 (lire en ligne)
  • (en) Jaein Jeong, Sukun Kim et Alan Broad, « Network reprogramming », TinyOS documentation.,‎ (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.,‎ (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,‎ (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,‎ , 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,‎ (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,‎ , 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,‎ , 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,‎ (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,‎ , 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,‎ , 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,‎ (lire en ligne)
  • (en) Anthony D. Joseph, « Operating Systems and Systems Programming Course Reader for Spring 2008 », University of California Berkeley Computer Science 162,‎ (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,‎ , 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,‎ (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,‎ , 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,‎ (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,‎ (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,‎ , 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,‎ (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,‎ , 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,‎ , 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,‎ , 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,‎ , 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,‎ , 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,‎ , 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,‎ (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,‎ (lire en ligne)
  • (en) Kang Lee, « IEEE P1451 Draft Standard for a Smart Transducer Interface for Sensors and Actuators », IEEE,‎ (lire en ligne)
  • (en) Kang Lee, « Brief Description of the Family of IEEE 1451 Standards », IEEE,‎ (lire en ligne)
  • (en) V.C. Gungor et G.P. Hancke, « Industrial Wireless Sensor Networks: Challenges, Design Principles, and Technical Approaches », IEEE,‎ , p. 4258 - 4265 (DOI 10.1109/TIE.2009.2015754, 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,‎ , p. 1567 - 1576 vol.3 (ISBN 0-7803-7476-2, DOI 10.1109/INFCOM.2002.1019408, lire en ligne)
  • (en) Veljko Krunic, Erico Trumpler et Richard Han, « NodeMD: Diagnosing Node-Level Faults in Remote Wireless Sensor Systems », ACM,‎ , p. 1 (ISBN 978-1-59593-614-1, lire en ligne)

Autres documents[modifier | modifier le code]

  • (en) Geoff V Merrett et Yen Kheng Tan, « Wireless Sensor Networks: Application-Centric Design », inTech,‎ , 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,‎ (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,‎ (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,‎ (lire en ligne)
  • (en) John T. Correll, « Igloo White », Air Force Magazine,‎ (lire en ligne)

Thèses[modifier | modifier le code]

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

Liens externes[modifier | modifier le code]

v · m
Apple
Mac OS Classic
Dérivés de NeXTSTEP
Dérivés de BeOS
DOS
IBM
Microsoft Windows
Fondés sur MS-DOS
Branche NT
ReactOS Foundation
Branche NT (GPL/LGPL/AGPL) non-Microsoft
POSIX / Unix
AT&T / Laboratoires Bell
BSD
GNU Hurd
Linux (liste)
Autres dérivés
Dérivés d'AmigaOS
Dérivés du TOS
D’importance historique
Mobile
Noyau Linux
Autres noyaux
Embarqués
Pour capteur en réseau
Pour carte à puce
Temps réel
Autres systèmes
Pour une liste complète, voir la liste des systèmes d’exploitation et la catégorie « Système d’exploitation ».
Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Système_d%27exploitation_pour_capteur_en_réseau&oldid=211289699 ».