Accueil🇫🇷Chercher

Contiki

Contiki est un système d’exploitation léger et flexible pour capteurs miniatures en réseau. Ces dernières années, le monde scientifique a porté une attention importante aux réseaux de capteurs sans fil[2]. La miniaturisation des capteurs et leur prix relativement faible[3], permettent d'imaginer des applications très variées dans les domaines scientifiques, militaires, industriels et domotiques[2]. Pour faciliter le développement de ces applications, une équipe du centre suédois de recherche scientifique SICS (en) a créé Contiki[4]. Destiné à être embarqué dans des capteurs miniatures ne disposant généralement que de ressources limitées, Contiki propose malgré tout les principales caractéristiques et fonctionnalités d'un système d'exploitation tout en favorisant une consommation énergétique et une empreinte mémoire minimales. Ses principaux atouts sont le support des protocoles IPv6 et 6LoWPAN, sa flexibilité et sa portabilité. Disponible gratuitement sous licence BSD, Contiki peut être utilisé et modifié, même à des fins commerciales.

Contiki
Capture d'Ă©cran de Contiki.
Capture d'Ă©cran de Contiki.

Plates-formes Multiplateforme
Entreprise /
DĂ©veloppeur
Adam Dunkels (en)
Licence BSD 3-clauses
Dernière version stable 4.8 ()[1]
Site web www.contiki-os.org

Récemment une nouvelle branche mise à jour a été créée:Contiki-NG

Fonctionnement et théorie

architecture de Contiki[5]

Écrit en langage C, Contiki est constitué d’un noyau, de bibliothèques, d’un ordonnanceur et d’un jeu de processus[6]. Comme tout système d'exploitation, son rôle est de gérer les ressources physiques telles que le processeur, la mémoire, les périphériques informatiques (d'entrées/sorties)[7]. Il fournit ensuite aux applications informatiques des interfaces permettant d'utiliser ces ressources[7]. Conçu pour les modules de capteurs sans fil miniatures, il occupe peu d'espace en mémoire et permet une consommation électrique très faible[8].

Contiki offre deux types de connectivité :

  • la couche Rime, elle permet un dialogue vers les capteurs voisins ainsi que le routage[9].
  • la couche uIP, orientĂ©e Internet, elle offre les services essentiels du protocole IP mais nĂ©cessite plus de ressources que Rime[10].

Pour économiser la mémoire, tout en fournissant un bon contrôle de flux dans le code, Contiki utilise un mécanisme appelé Protothreads[11]. Protothreads est un compromis entre la programmation événementielle et la programmation multi-threads[12]. Contiki gère les standards 6LoWPAN, RPL[13], CoAP[14]. Le système de fichier Coffee permet des opérations sur des fichiers stockés sur une mémoire flash externe[15]. Contiki offre également des services comme un serveur telnet fournissant un accès similaire à un Shell Unix, un serveur web, une interface graphique fournie par un serveur VNC et d'autres fonctionnalités comme un navigateur web.

Les caractéristiques

Un système d'exploitation pour capteur en réseau a différentes caractéristiques :

Empreinte mémoire

L'espace mémoire utilisé par le système d'exploitation et par l'application doit être suffisamment faible pour être contenu dans la mémoire du capteur. Une configuration typique de Contiki (le noyau et le chargeur de programmes) consomme 2 kilooctets de RAM et 40 kilooctets de ROM[16].

Consommation Ă©lectrique

L'énergie électrique, souvent apportée par une batterie de piles, peut être problématique à renouveler[7]. Si des systèmes de captage, comme des éléments photovoltaïques, éoliennes, ou autres peuvent être utilisés dans certains cas, les recherches scientifiques explorent les possibilités de réduire la consommation des capteurs. L'élément le plus consommateur est le module radio[17]. La réduction de temps de transmission et de réception radio est primordiale. Pour cela, le module radio est activé lorsque nécessaire, et arrêté ou mis en veille le reste du temps[17]. Mais lorsque le module radio est arrêté, le capteur ne reçoit pas les messages qui lui sont destinés[17]. Un réveil périodique risque d'être inutile, et donc de consommer de l'énergie de façon inefficace[17]. Pour gérer cette problématique, Contiki propose par défaut ContikiMAC, un mécanisme conçu pour rester en communication avec le réseau efficacement, tout en permettant la mise hors tension du module radio 99 % du temps [17]. D'autres techniques permettent de limiter la consommation tel que le compactage des données à transférer, le pré-calcul (afin de ne transmettre que les données réellement utiles), mais aussi une optimisation du routage[18]. Dans certains cas, il peut être utile de stocker des informations dans une base de données locale au capteur, telle qu'Antelope[19], en effet, si le capteur doit envoyer un ensemble de mesures semblables à des résultats déjà envoyés à un autre moment, il peut être préférable d'envoyer une référence à ces données déjà envoyées (Parcourir 100 enregistrements dans une base coûte moins d'énergie que de transmettre un paquet radio)[20].

Communications

Contiki implémente 2 mécanismes de communication :

  1. la couche de protocole Rime[21]. Elle fournit à la couche applicative un jeu d'instructions de communication, permettant les différentes connexions avec les capteurs voisins. Les applications ou protocoles exécutés au-dessus de la couche Rime peuvent utiliser une ou plusieurs instructions de communication fournies par la couche Rime. Rime peut être associé au mécanisme Chameleon afin de s'adapter aux protocoles de la couches MAC. Chameleon gère la création, la lecture et la transformation des entêtes des protocoles de la Couche liaison de données du modèle OSI et communique avec la couche Rime en associant des attributs aux paquets. Les informations importantes des entêtes des protocoles inférieurs pourront ainsi remonter vers la couche applicative ou le protocole situé au-dessus de la couche Rime[22].
  2. la couche uIP. Contiki implĂ©mente uIPv4 et uIPv6. uIP supporte les protocoles IP, TCP, UDP et ICMP[10]. uIPv6 est la première implĂ©mentation d'IPv6 pour capteurs miniatures Ă  avoir obtenu le label IPv6 Ready Phase-1[23], elle rĂ©pond aux exigences de la RFC4229[24]. Pour les communications radio via le protocole IEEE 802.15.4, Contiki implĂ©mente 6LoWPAN. Lors de communications radio suivant la norme IEEE 802.15.4 communĂ©ment utilisĂ©e par les capteurs[25], la taille d'un paquet est limitĂ©e Ă  127 octets, ce qui est insuffisant pour transmettre un paquet IPv6 dont la taille maximum est de 1 280 octets[26]. L'IETF a crĂ©Ă© une couche d'adaptation 6LoWPAN qui se situe entre les couches liaison et rĂ©seau du modèle OSI. 6LoWPAN permet la compression de l'entĂŞte du paquet IPv6 ainsi que la fragmentation et le rĂ©-assemblage des datagrammes. Pour le routage d'IPv6 Ă  travers le rĂ©seau de capteur, Contiki intègre ContikiRPL[18] dans la couche uIPv6, une implĂ©mentation du protocole de routage RPL[13] (routing protocol for Low power and Lossy Networks).

Portabilité

La portabilité consiste à adapter le système d'exploitation aux capteurs, selon les éléments électroniques les constituant. Contiki est complètement écrit en langage C, ce langage de programmation est le langage le plus répandu pour la programmation des systèmes [27]. La plupart des constructeurs de microprocesseurs et de micro-contrôleur fournissent une solution de compilation croisée permettant de compiler sur une machine de type PC le code source écrit en C afin d'obtenir un programme en langage machine qui sera compris par le microprocesseur. Le portage de Contiki est effectué pour les plateformes suivantes[28]: exp5438, RE-mote, Firefly, Zoul, wismote, avr-raven, avr-rcb, avr-zigbit, iris, micaz, redbee-dev, redbee-econotag, mb851, mbxxx, sky, jcreate, sentilla-usb, msb430, esb, avr-atmega128rfa, cc2530dk, sensinode ainsi que sur apple2enh, atari, c128, c64

Interopérabilité

L’interopérabilité d'un capteur est le fait de pouvoir communiquer avec des capteurs gérés par un système d'exploitation différent. Adams Dunkels de l'équipe scientifique suédoise présente dès 2003 uIP et lwIP permettant d'implémenter le protocole IP sur les systèmes limités en ressources tel que les capteurs[29]. Jusque-là, les capteurs utilisaient des protocoles de communication propriétaires ou alors des adaptations d'IP permettant le fonctionnement des applications mais sans offrir toutes les fonctionnalités du protocole IP[30] - [31]. Dès la présentation de Contiki en 2004, uIP et lwIP étaient disponibles. De ce fait, les applications exécutées sur Contiki pouvaient dialoguer vers n'importe quel matériel supportant le protocole IP. L'arrivée de IPv6 et uIPv6 sur Contiki apporte une nouvelle interopérabilité vers les matériels supportant ce protocole. Le support de 6LoWPAN permet à Contiki de communiquer avec les matériels via un réseau sans-fil suivant la norme 802.15.4. Contiki est réputé pour être un système d'exploitation robuste et mature, fournissant IPv4 et IPv6 pour les réseaux de capteurs sans-fil[32]. Selon une étude publiée en 2011, comprenant des tests d'interopérabilité entre des capteurs sous Contiki et d'autres sous TinyOS, l'interopérabilité est bien au rendez-vous, mais des efforts sont à faire pour mesurer et améliorer les performances des couches réseaux[33].

Accès distant

interface graphique de Contiki

Contiki propose plusieurs moyens de connexion Ă  distance :

  1. un serveur telnet
  2. un serveur web
  3. un web service
  4. une interface graphique via un serveur VNC

Autres

Le code source de Contiki contient un répertoire apps[34] dans lequel on trouve des applications optionnelles :

  1. un shell de commandes : Contiki propose également dans ses options un shell de commandes dans le style unix. Un certain nombre de commandes utiles au développement et au debug sont disponibles. Comme dans un Shell Unix, les commandes peuvent s'enchainer à travers un pipe. Le développeur peut enrichir le shell avec ses propres commandes.
  2. un navigateur web
  3. un client ftp
  4. un client dhcp
  5. un client mail
  6. un client de messagerie instantanée IRC
  7. un analyseur/générateur JSON
  8. un client telnet
  9. un client twitter
  10. une calculatrice
  11. ....

Mise Ă  jour, ou mise en place de nouvelles applications Ă  distance

Chargement en mémoire du système et des programmes[35]

Contiki est un système d'exploitation modulaire. Contrairement à un système d'exploitation monolithique où le système complet ainsi que les applications sont enregistrées dans un fichier binaire qui est chargé d'un seul bloc dans l'EEPROM du capteur, sur Contiki le fichier binaire contient uniquement le système, les applications sont enregistrées séparément sous forme de modules. Contiki réalise le chainage des références de façon dynamique (Dynamic Linking (en)), les modules sont au format ELF qui est le format par défaut produit par le compilateur GCC, ou bien au format Compact ELF[36]. Contiki peut ainsi charger et décharger des applications dynamiquement, ce qui permet une flexibilité pour la maintenance et la mise à jour de ces applications[37]. Ce système modulaire apporte plusieurs avantages :

  1. Réduction de la consommation d'énergie. Lors d'une mise à jour applicative, seuls les modules concernés seront transférés[38].
  2. Réduction de l'utilisation de la mémoire vive : Le fait de ne charger les programmes qu'en temps utile réduit l'utilisation de la mémoire[39].
  3. Simplification de la maintenance du code : Le système est compilé une seule fois par type de capteur. La maintenance du code se fera par module applicatifs, qui pourront être chargés différemment selon les fonctions des capteurs dans le réseau[37].

La présentation de Snap par Simon Duquennoy montre que la mise à jour ou l'installation d'une nouvelle application peut se faire d'une façon extrêmement simple à l'aide d'un smartphone via un stockage d'applications pour capteurs (a sensornet appstore)[40].

Accès à une mémoire morte externe à l'aide d'un système de fichier

L'utilisation sur les capteurs d'une mémoire morte complémentaire de type mémoire flash se généralise par la présence d'un lecteur de carte microSD. Plusieurs facteurs expliquent cela : le faible coût, le faible encombrement et la résistance aux chocs, la taille importante de la capacité de stockage allant de nos jours jusqu'à plusieurs Gigaoctets. L'utilisation de ce type de mémoire apporte divers avantages :

  1. l'archivage des valeurs mesurées afin d'optimiser leur diffusion en mode différé[41]. L'écriture des données sur une carte SD, puis la lecture des données, leur traitement et l'envoi en paquets peut être plus économe en énergie que la transmission en direct des données via le module radio[42].
  2. le stockage des modules applicatifs, modules qui seront chargés dynamiquement par les programmes[43].
  3. l'utilisation de mémoire virtuelle[44].
  4. le stockage d'une base de données[45].

Contiki implĂ©mente un système de fichiers ou filesystem nommĂ© Coffee[46]. Coffee a l'avantage d'utiliser peu de RAM, son empreinte mĂ©moire est infĂ©rieure Ă  200 octets, et chaque fichier ouvert nĂ©cessite 15 octets supplĂ©mentaires lorsque l'offset est de 32 bits[47].

Gestion du multi-threading

Contiki utilise un ordonnanceur Ă©vĂ©nementiel. Un Ă©vĂ©nement matĂ©riel ou logiciel dĂ©clenche l’exĂ©cution d'un processus qui sera menĂ© Ă  son terme avant de rendre la possibilitĂ© Ă  l'ordonnanceur de dĂ©marrer l’exĂ©cution d'une nouvelle tâche. Ce type d'ordonnancement est le plus Ă©conome en ressource et est gĂ©nĂ©ralement adaptĂ© Ă  l'utilisation des capteurs sur lesquels un Ă©vĂ©nement extĂ©rieur est souvent Ă  l'origine d'un nouveau traitement. Le multi-threading est plus flexible, il permet au programmeur de faire abstraction des appels systèmes, mais il est consommateur de ressources mĂ©moire, car chaque thread nĂ©cessite son contexte d’exĂ©cution en mĂ©moire[48]. Pour permettre l’exĂ©cution en parallèle de plusieurs tâches, (par exemple de services), contiki apporte le concept des protothreads[11]. Ce concept se situe entre les 2 modèles, Ă©vĂ©nementiels et multi-threads. Il permet de bloquer l'exĂ©cution d'un programme dans l'attente d'un Ă©vĂ©nement ou d'une condition particulière. Le programme reprend son exĂ©cution lorsque l'Ă©vĂ©nement attendu est survenu. Contrairement au multi-threading, oĂą chaque thread dispose de son contexte mĂ©moire, les protothreads partagent le mĂŞme contexte d’exĂ©cution. Le surcout mĂ©moire d'un protothread est de 2 octets, ce qui correspond Ă  l'espace nĂ©cessaire au stockage de l'adresse du pointeur permettant de rappeler le programme au niveau oĂą le blocage est intervenu[49]. Par contre les variables locales ne sont pas maintenues ni restaurĂ©es lors de la reprise du programme[50], ce qui risque de rendre le code instable[51]. Les protothreads permettent au programmeur de coder avec de simples instructions conditionnelles les attentes d'Ă©vĂ©nements, ils simplifient donc l'Ă©criture du code et diminuent de par ce fait le nombre de lignes Ă  Ă©crire[52]. Mais le multi-thread permet des exĂ©cutions en parallèle, ce qui peut ĂŞtre indispensable, par exemple pour des applications en temps rĂ©el. Contiki propose une bibliothèque qui peut ĂŞtre chargĂ©e par le programmeur si son application nĂ©cessite le multi-threading.

Exécution d'applications en temps réel

Contiki n'est pas un système d'exploitation permettant l'exécution d'applications en temps réel[53]. Bien qu'il soit possible de charger la bibliothèque permettant d'exécuter des threads en parallèle, le multi-threading est chargé par-dessus l’ordonnanceur événementiel. Une tâche lancée par l'ordonnanceur en mode événementiel ne peut pas être interrompue par les tâches exécutée en mode multi-thread.

Sécurité des données et des transmissions

Contiki implémente ContikiSec[54] qui permet au développeur de choisir entre trois niveaux de sécurité pour les transmissions radio[55] :

  1. un mode confidentiel, celui-ci est obtenu par le chiffrement des blocs de donnés transmis.
  2. un mode d'authentification seul, s'assure de l'authenticité du partenaire.
  3. un mode confidentiel et authentifié, c'est la somme des deux modes précédents.

Le pare-feu AEGIS[56], conçu pour les systèmes d'exploitation modulaires, est compatible avec Contiki[57]. Il permet le filtrage des paquets entrants et sortants.

La simulation

Contiki propose un simulateur de réseau appelé Cooja. Ce simulateur permet l'émulation de différents capteurs sur lesquels seront chargés un système d'exploitation et des applications. Cooja permet ensuite de simuler les connexions réseaux et d'interagir avec les capteurs. Cet outil permet aux développeurs de tester les applications à moindre coût. Les capteurs supportés[28] à ce jour par Cooja sont : exp5438, z1, wismote, micaz, sky, jcreate, sentilla-usb, esb.

Une interface de développement

Pour simplifier le développement, Contiki propose un environnement de développement complet et fonctionnel nommé Instant Contiki[58], téléchargeable sous la forme d'une machine virtuelle VMware. Cette machine virtuelle peut être lancée par VMware Player[59] qui est fourni gratuitement sur le site de VMware. Cette machine virtuelle contient un environnement de développement Eclipse et tout le code source de contiki avec quelques exemples. Elle contient également le simulateur Cooja avec plusieurs exemples de simulations.

Systèmes existants

Présentation

Les articles de Dong de 2010[60] et 2011[61] ainsi que celui de Saraswat de 2010[62] recensent les principaux systèmes d'exploitation pour les réseaux de capteurs sans fil: TinyOS[63], Contiki, SOS[64], Mantis OS[65], Nano-RK (en)[66], LiteOS[67], RETOS[68], SenSpireOS[64], Riot OS, et en décrivent sommairement les caractéristiques.

L'état de l'art de mai 2011[69] s'intéresse aux plus populaires. Y sont développés l'architecture, le modèle d'exécution du système, la gestion de l'énergie, la gestion de la mémoire, la reprogrammation, la sécurité, l'ordonnancement et les protocoles de communication pour les cinq OS suivants : TinyOS[70], Contiki[71], Mantis OS[72], Nano-RK (en)[73], LiteOS[74].

De nombreux systèmes d'exploitation disponibles sont également cités dans l'article de 2011[75], mais ne sont détaillés et comparés que les deux qu'ont privilégié les développeurs, TinyOS et Contiki, et le dernier arrivé sur le marché, LiteOS. Il est également souligné que Contiki est le premier système d'exploitation pour capteur sans fils à établir une communication avec une pile TCP/IP uIP. En 2008, Contiki implémente uIPv6, la plus petite stack (pile) ipv6 au monde [76].

Le même choix se retrouve dans le document de 2010[77], qui détaille également TinyOS et Contiki, en rajoutant Mantis. Les auteurs font ce choix car ces trois OS sont les plus importants et les plus utilisés dans le domaine des WSN, et au vu du nombre de publications scientifiques concernant ces système d'exploitation dans les bases IEEE Xplore, ACM Digital Library[78] et Science Direct[79]. Les pourcentages sont de 81 % pour TinyOS, 9 % pour Contiki, 8 % pour Mantis et de 2 % pour les autres[80].

Enfin dans un article d’août 2012, on retrouve encore ce choix, puisque les auteurs précisent qu'il existe un grand nombre de systèmes d'exploitation pour WSN mais ne comparent que TinyOS et Contiki qu'ils jugent deux des meilleurs[81] :

Caractéristiques [82] des systèmes d'exploitation pour WSN référencés dans l'état de l'art de 2011[69]
TinyOS Contiki Mantis Nano-RK LiteOS
Publication (année) ASPLOS (2000) EmNets (2004) MONET (2005) RTSS (2005) IPSN (2008)
Statique/Dynamique Statique Dynamique Dynamique Statique Dynamique
Événementiel/Thread Event&Thread

(TinyThread, TOSThreads)

Event&Threads

(Protothreads)

Thread&Event

(TinyMOS)

Thread Event&Thread

(through callback)

Monolithique/Modulaire Monolithique Modulaire Modulaire Modulaire Modulaire
RĂ©seau Message Actif uIP, uIPv6, Rime "comm" socket File-Assisted
Langage de programmation nesC C C C LiteC++
Système de fichier Un seul niveau Coffee non non Hiérarchique de type Unix
Reconfiguration oui oui non non oui
DĂ©bogage distant oui non oui non oui

Les caractéristiques

En comparant les caractéristiques importantes [83] de TinyOS, Contiki et LiteOS, il en ressort que Contiki et LiteOS, avec leurs systèmes dynamiques et modulaires sont, contrairement à TinyOS basé sur un système statique et monolithique, plus flexibles et donc plus adaptés pour un changement d'environnement dynamique ou dans le cas d'une reprogrammation au travers du réseau. Cette flexibilité de Contiki par rapport à TinyOS est également confirmée dans l'article d'août 2012 [84].

  • Le système d'exploitation de Contiki, contrairement Ă  TinyOS Ă©crit en NesC ou celui de LiteOS Ă©crit en LiteC++, est codĂ© en langage C ce qui le rend très portable[85]. L'article de Laraja [86] prĂ©cise que la programmation en C implique une courbe d'apprentissage beaucoup moins raide que celle nĂ©cessaire en NesC pour lequel les dĂ©veloppeurs doivent s'approprier un nouveau paradigme dans les concepts tel que les modules, les composants, les interfaces ou configurations. La programmation complexe en NesC permet d'obtenir un code lĂ©ger. Ce point est Ă©galement soulignĂ© par Philip Levis dans son article retraçant le dĂ©veloppement de TinyOS sur la dernière dĂ©cennie. Il y prĂ©cise qu'aujourd'hui, mĂŞme si TinyOS est plus lĂ©ger et efficace, la majoritĂ© des recherches autour des rĂ©seaux de capteur sans fil se fait avec Contiki qui est plus facile d'apprentissage[87].
  • L'implĂ©mentation du mĂ©canisme de multithreads est Ă©galement diffĂ©rente puisque liteOS la gère nativement, TinyOS uniquement grâce Ă  sa bibliothèque TinyThreads, et contiki obtient ce mode d'exĂ©cution soit par bibliothèque, soit par protothreads[89]. Le protothread [11] de contiki rĂ©duit l'utilisation mĂ©moire, au dĂ©triment de certaines fonctionnalitĂ©s comme le maintien des variables locales[90].
  • La pile rĂ©seau de TinyOS est la plus lĂ©gère, elle est basĂ©e sur le principe de messages pondĂ©rĂ©s (en). Celle de LiteOS est basĂ©e sur un principe de fichier type commande Shell Unix. Contiki quant Ă  lui contient 2 couches de communication, Rime et uIP qui lui permettent de communiquer avec les protocoles de l'internet, y compris en IPv6. Contiki implĂ©mente uIPv6, la plus petite couche IPv6 au monde, utilisable dans le domaine des capteurs sans fils[83].
  • Concalves [91] montre que les mĂ©canismes de mise en veille sont implĂ©mentĂ©s diffĂ©remment sur les quatre OS comparĂ©s. Le processeur de TinyOS est mis en veille lorsque sa file de traitement est vide, celui de Nano-RH lorsque toutes les tâches sont suspendues, celui de Mantis lorsque tous les threads ont demandĂ© la mise en sommeil, et celui de Contiki lorsque l'application le dĂ©cide.
  • L'empreinte mĂ©moire du noyau de Contiki est aussi plus importante que celle de TinyOS qui ne propose qu'un ordonnancement FIFO, contrairement Ă  Contiki qui permet en plus la gestion de prioritĂ©s[92].
  • Concernant le mĂ©canisme de mise Ă  jour dynamique du logiciel, il est natif sur LiteOS et Contiki[83].

TinyOS / Contiki

Une expérimentation[93] réalisée par un centre de recherche Brésilien, compare TinyOS et Contiki lorsqu’ils sont implémentés sur un capteur de type Crossbow TelosB. Les tâches sont plus rapidement exécutées avec Contiki, mais TinyOs est moins consommateur. Pour l’exécution d’algorithme de sécurité, les résultats des 2 OS sont similaires. Les tâches de communication fonctionnent mieux sur TinyOS, probablement en raison d'une utilisation plus efficace de la pile de communication. Les résultats ont montré que les deux OS peuvent être optimisés pour réduire la consommation d'énergie lorsqu’ils sont paramétrés en conséquence par les développeurs. TinyOS et Contiki ont été validés sur de multiples plates-formes matérielles[94] - [95]. Mais, l'article [84] précise que généralement TinyOS peut fonctionner avec des conditions de ressource inférieure liées au fait que le noyau Contiki est plus complexe. L'article précise aussi que TinyOS est plus adapté lorsqu'une faible empreinte mémoire est la priorité. Par contre si la flexibilité est prioritaire, le choix se portera sur Contiki.

Dans le cas d'un scénario d'une ville intelligente où TinyOS et Contiki sont en concurrence, Contiki est privilégié d'abord parce qu'il est écrit en C et surtout à cause de sa caractéristique majeure : la petite taille de sa pile uIP[96].

Concernant l'interopérabilité entre les deux OS, elle fonctionne bien, lorsque la couche Contiki-MAC et TinyOS est correctement paramétrée[97].

Applications et perspectives

Les réseaux de capteur sans fil peuvent être utilisés dans des domaines très différents comme l'agriculture de précision, l'industrie, la santé, le domaine militaire, le contrôle environnemental, la surveillance de l'habitat, la détection et la sécurité etc[98] - [99].Cette technologie ouvre la voie de l'internet des objets, et permettra de créer des applications et des services pour rendre les villes, les maisons et les objets intelligents[100].

Applications

Les applications WSN peuvent être réparties en deux catégories[31], celles basées sur les technologies IP comme Contiki, et les autres implémentant des standards WSN comme wirelessHart (en), ZigBee ou d'autres protocoles propriétaires. Aujourh'hui, avec les microcontrôleurs 32 bits, l'optimisation des piles de protocoles et la disponibilité du grand nombre d'adresse IPv6, la tendance est d'utiliser les technologies de l'internet[101]. Avec sa propre adresse IP chaque objet intelligent se connecte nativement à l'internet pour former l'internet des objets[102].

  • Le projet INGA utilise Contiki pour son rĂ©seau de capteurs sans fils de mouvement et de position. Les mesures de l'accĂ©lĂ©romètre, du gyroscope et des capteurs de pression, dĂ©tectent le mouvement et la position en temps rĂ©el avec une visualisation possible en 3D grâce Ă  une transmission TCP/IPv6 sur connexion IEEE 802.15.4. Les premières applications se font dans le domaine de la santĂ© pour la surveillance des personnes âgĂ©es, et dans le domaine de l'aĂ©ronautique (quadrocopters (en))[103].
  • Le projet de SICS (en) pour contrĂ´ler l'environnement marin[104] met en Ĺ“uvre un rĂ©seau de capteurs se servant de Contiki Coffee pour stocker une grande quantitĂ© de donnĂ©es et limiter ainsi des tâches trop consommatrices d'Ă©nergie.
  • Le projet NOBEL[106] rĂ©alise une infrastructure qui met en rĂ©seau des compteurs intelligents grâce Ă  Contiki. Ce système surveille les rĂ©seaux Ă©lectriques tout en permettant aux fournisseurs d'Ă©lectricitĂ© d'optimiser la tension Ă©lectrique dĂ©livrĂ©e.

Perspectives

Pour déployer un Internet des objets fiable, robuste et efficace, des recherches plus approfondies sont nécessaires dans le domaine de la technologie d'identification, dans le domaine des protocoles de communication, pour interopérabilité et dans les architectures distribuées [107].

D’après les articles étudiés, les recherches futures concernant Contiki vont porter sur :

  • l’amĂ©lioration de l'algorithme de compression EXI (en) pour utiliser plus efficacement la mĂ©moire RAM [108]
  • L’amĂ©lioration de la fiabilitĂ© de LoWPAN et les solutions WSN avec une mobilitĂ© des capteurs ou une connectivitĂ© intermittente. Les recherches qui ne sont pour l’instant qu’experimentales vont se diriger vers des applications rĂ©elles afin de tester la performance de 6LoWDTN[109]
  • Les possibilitĂ©s et les limitations d’une architecture RESTful dans le domaine IoT, son fonctionnement en termes de latence, sa fiabilitĂ© et la durĂ©e de vie de la batterie[110].
  • Enrichissement de l'interopĂ©rabilitĂ© des rĂ©seaux de capteurs[111]

La création de Thingsquare Mist[112], logiciel open-source embarquant Contiki, utilise des standards tels que IPv6, 6LoWPAN, le protocole de routage RPL et le standard de chiffrement avancé AES. Il donne la possibilité aux concepteurs de systèmes intelligents de connecter facilement leurs appareils à des réseaux existants basés sur le protocole Internet IP (éclairage, des villes, des habitations et des immeubles ). Thingsquare Mist[112] facilite énormément le développement et le déploiement de l'Internet des objets. Thingsquare[113] collabore avec plusieurs fabricants majeurs de matériel informatique afin d'adapter Thingsquare Mist à une large gamme de plateformes matérielles. Thingsquare Mist est actuellement en phase bêta privée auprès d'un ensemble de clients sélectionnés et sera disponible au cours du premier trimestre 2013.

Un nombre important de recherches, concernant l'internet des objets sont financés par des pays, des multinationales et même la Commission européenne[114]. Dans ce cadre, cette dernière a lancé le projet Calipso[115], qui interconnecte des objets intelligents par le biais de réseaux de capteurs sans fil en IPv6, embarquant le système d'exploitation contiki, pour des applications diverses : infrastructures intelligentes, villes intelligentes, objets intelligents[116].

Historique

2003

Présentation par Adam Dunkels de FULL TCP/IP sur une architecture 8 bits[117].

2004

CONTIKI présenté par Adam DUNKELS, Björn GRONVALL et Thiemo VOIGT à Tampa en Floride USA, lors de la 29e conférence annuelle de l’IEEE à l’occasion du premier atelier de l’IEEE sur les capteurs en réseau[4].

décembre 2007

Contiki 2.1

juillet 2008

Contiki 2.2

Collaboration de Cisco Systems pour implèmenter Open-source uIPv6. Making sensor networks IPv6 ready[118].

juin 2009

Contiki 2.3

ContikiSec: A Secure Network Layer for Wireless Sensor Networks under the Contiki Operating System[119].

février 2010

Contiki 2.4

septembre 2011

Contiki 2.5

A Low-Power CoAP for Contiki[120].

Low-power wireless IPv6 routing with ContikiRPL[121].

ContikiMAC, mecanisme qui permet de mettre les capteurs en veille 99 % du temps dans le but de reduire la consommation d'Ă©nergie[122].

juillet 2012

Contiki 2.6

septembre 2012

Dans le but de développer un ensemble de produits logiciels basé sur Contiki, Fredrik Österlind, Roger Bergdahl et Adam Dunkels fondent une société nommée Thingsquare[113] qui fournit des logiciels open-source destinés à l'Internet des objets.

octobre 2012

Commercialisation de Thingsquare Mist[123], une plate-forme dédiée aux marchés de la domotique, de l’automatisation des bâtiments et de l’éclairage intelligent.

Notes et références

Notes

    Références

    1. « https://github.com/contiki-ng/contiki-ng »
    2. Farooq 2011, p. 5900
    3. Barton 2008, p. 105-125
    4. Dunkels 2004, p. 455-462
    5. Farooq 2011, p. 5910
    6. Moubarak 2009, p. 336
    7. Farooq 2011, p. 5901
    8. Lajara 2010, p. 5819-5820
    9. Dunkels 2007, p. 7
    10. Farooq 2011, p. 5911
    11. Dunkels 2006, p. 29-42
    12. Moubarak 2009, p. 335
    13. IETF RFC RPL 2012
    14. Constrained Application Protocol (CoAP) 2012
    15. Tsiftes 2009, p. 449-460
    16. Farooq 2011, p. 5909
    17. Dunkels 2011, p. 1
    18. Tsiftes 2010, p. 406
    19. Tsiftes 2011, p. 316-329
    20. Tsiftes 2011, p. 316
    21. Dunkels 2007, p. 7-9
    22. Dunkels 2007, p. 4-7
    23. Durvy 2008, p. 422
    24. IETF RFC 4229 2012
    25. Korte 2012, p. 50
    26. Roth 2012, p. 78
    27. TIOBE Programming Community IndexProgramming Language Popularity
    28. Contiki hardware 2012
    29. Dunkels 2003, p. 85-98
    30. Dunkels 2003, p. 86
    31. He 2011, p. 507
    32. He 2011, p. 508
    33. Ko 2011, p. 10
    34. Code source apps 2012
    35. Dunkels 2006, p. 19
    36. Dunkels 2006, p. 18
    37. Min 2008, p. 822
    38. Dunkels 2006, p. 16
    39. Dunkels 2006, p. 25
    40. Duquennoy 2011, p. 405-406
    41. Dai 2004, p. 176
    42. Healy 2009, p. 1415
    43. Dunkels 2006, p. 17
    44. Gu 2006, p. 3
    45. Tsiftes 2011, p. 322-324
    46. Tsiftes 2009, p. 349-360
    47. Tsiftes 2009, p. 357
    48. Hyoseung 2007, p. 294
    49. Dunkels 2006, p. 30
    50. Hyoseung 2007, p. 306
    51. Sallai 2005, p. 157
    52. Dunkels 2006, p. 41
    53. Farooq 2011, p. 5912
    54. Casado 2009, p. 133-147
    55. Casado 2009, p. 144
    56. Hossain 2010, p. 258-272
    57. Hossain 2010, p. 265
    58. Instant Contiki 2012
    59. VMware Player download 2012
    60. Dong 2010, p. 519
    61. Dong 2011, p. 1798-1799
    62. Saraswat 2010, p. 41-45
    63. TinyOS
    64. SOS
    65. MantisOS
    66. Nano-RK
    67. LiteOS
    68. RETOS
    69. Farooq 2011, p. 5900-5930
    70. Farooq 2011, p. 5905-5909
    71. Farooq 2011, p. 5909-5913
    72. Farooq 2011, p. 5913-5917
    73. Farooq 2011, p. 5917-5921
    74. Farooq 2011, p. 5921-5924
    75. Chien 2011, p. 74
    76. Chien 2011, p. 76
    77. Lajara 2010, p. 5812-5814
    78. ACM
    79. ScienceDirect o
    80. Lajara 2010, p. 5812
    81. Carle 2012, p. 7
    82. Dong 2010, p. 522
    83. Chien 2011, p. 77
    84. Carle 2012, p. 12
    85. Chien2011 2011, p. 76
    86. Lajara et 2010 p5824
    87. Levis 2012, p. 213
    88. Saraswat 2010, p. 45
    89. Chien 2011, p. 78
    90. Chu 2013, p. 139
    91. Goncalves 2011, p. 17
    92. Saraswat2010 2010, p. 45
    93. Margi et 2010 P1-6
    94. Lajara et 2010 p5809-5826
    95. Oikonomou et 2011 p1-6
    96. Fazio 2012, p. 779
    97. Ko 2012, p. 96
    98. Liu 2012, p. 22
    99. Chien 2011, p. 73
    100. Fazio 2012, p. 775
    101. Mainetti 2011, p. 3
    102. Mainetti 2011, p. 1
    103. Wolf 2011, p. 435-436
    104. ERCIM News - Environnement marin
    105. WismoteMini
    106. SicsNobel
    107. Bandyopadhyay 2011, p. 66
    108. Caputo 2011, p. 774
    109. Bruno 2011, p. 5
    110. Kovatsch 2011, p. 860
    111. He 2011, p. 510
    112. Thingsquare news 2012
    113. Thingsquare
    114. Coetzee 2011, p. 1
    115. EU_Calipso
    116. ICT_Calipso
    117. Dunkels 2003
    118. Durvy 2008, p. 421-422
    119. Casado 2009, p. 147
    120. Kovatsch 2011, p. 855-860
    121. Tsiftes 2010, p. 406-407
    122. Dunkels 2011
    123. ThingsquareMist

    Bibliographie

    • (en) John BARTON et Erik JUNG, « Distributed, Embedded Sensor and Actuator Platforms », Ambient Intelligence with Microsystems,‎ , p. 105-129 (ISBN 978-0-387-46263-9, DOI 10.1007/978-0-387-46264-6_5)
      différents capteurs
    • (en) Georg CARLE, Corinna SCHMITT et Alexander KLEIN, « Comparison of Operating Systems TinyOS and Contiki », Sensor Nodes – Operation, Network and Application,‎ (ISBN 3-937201-28-9, ISSN 1868-2634, DOI 10.2313/NET-2012-08-2_2)
      Proceedings of the Seminar Sensor Nodes – Operation, Network and Application (SN) Technische Universität München -Summer Semester 2012 -
    • (en) Lander CASADO et Philippas TSIGAS, « ContikiSec: A Secure Network Layer for Wireless Sensor Networks under the Contiki Operating System », NordSec '09 Proceedings of the 14th Nordic Conference on Secure IT Systems: Identity and Privacy in the Internet Age,‎ , p. 133-147 (ISBN 978-3-642-04765-7, DOI 10.1007/978-3-642-04766-4_10)
    • (en) Thang VU CHIEN, Hung NGUYEN CHANN et Thanh NGUYEN HUU, « A Comparative Study on Operating System for Wireless Sensor Networks », ICACSIS,‎ (ISBN 978-979-1421-11-9, lire en ligne)
    • (en) Rui CHU, Lin GU et Yunhao LIU, « SenSmart: Adaptive Stack Management for Multitasking Sensor Networks », IEEE TRANSACTIONS ON COMPUTERS,‎ , p. 137 (DOI 10.1109/TC.2011.238)
    • (en) Louis COETZEE et Johan EKSTEEN, « The Internet of Things – Promise for the Future? An Introduction », IST-Africa 2011 Conference Proceedings - Springer Science+Business Media, LLC. 2011,‎ , p. 1-9 (ISBN 978-1-905824-26-7)
    • (en) Debasis BANDYOPADHYAY et Jaydip SEN, « Internet of Things: Applications and Challenges in Technology and Standardization », Wireless Pers Commun 2011,‎ , p. 49-69 (DOI 10.1007/s11277-011-0288-5)
    • (en) Hui DAI, Michael NEUFELD et Richard HAN, « ELF: an efficient log-structured flash file system for micro sensor nodes », SenSys '04 Proceedings of the 2nd international conference on Embedded networked sensor systems,‎ , p. 176-187 (ISBN 1-58113-879-2, DOI 10.1145/1031495.1031516)
      Présentation de ELF Filesystem
    • (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)
    • (en) Wei. DONG, Chum. CARLSON, Xue. LIU, Yunhao. LIU, Jiajun. BU et Kougen. ZHENG, « SenSpire OS: A Predictable, Flexible, and Efficient Operating System for Wireless Sensor Networks », IEEE Computer Society Washington, vol. 60, no 4,‎ , p. 1788-1801 (DOI 10.1109/TC.2011.58)
    • (en) Adam DUNKELS, « Full TCP/IP for 8-bit architectures », MobiSys '03 Proceedings of the 1st international conference on Mobile systems, applications and services,‎ , p. 85-98 (DOI 10.1145/1066116.1066118)
      uIP et lwIP
    • (en) Adam DUNKELS, Björn GRONVALL et Thiemo VOIGT, « Contiki - A Lightweight and Flexible Operating System for Tiny Networked Sensors », Proceedings of the 29th Annual IEEE International Conference on Local Computer Networks,‎ , p. 455-462 (ISBN 0-7695-2260-2, ISSN 0742-1303, DOI 10.1109/LCN.2004.38)
      Présentation de contiki lors de la 29e conférence annuelle de l'IEEE
    • (en) Adam DUNKELS, Oliver SCHMIDT, Thiemo VOIGT et Muneeb ALI, « Protothreads: simplifying event-driven programming of memory-constrained embedded systems », Proceedings of the 4th international conference on Embedded networked sensor systems,‎ , p. 29-42 (ISBN 1-59593-343-3, DOI 10.1145/1182807.1182811)
      Présentation des protothreads lors de la 4e conférence ACM sur les systèmes de capteurs en réseau, à Boulder, Colorado, USA
    • (en) Adam DUNKELS, Niclas FINNE, Joakim ERIKSSON et Thiemo VOIGT, « Run-time dynamic linking for reprogramming wireless sensor networks », SenSys '06 Proceedings of the 4th international conference on Embedded networked sensor systems,‎ , p. 15-28 (ISBN 1-59593-343-3, DOI 10.1145/1182807.1182810)
      Chargement dynamique des programmes
    • (en) Adam DUNKELS, Frederik OSTERLIND et Zhitao HE, « An adaptive communication architecture for wireless sensor networks », SenSys '07 Proceedings of the 5th international conference on Embedded networked sensor systems,‎ , p. 335-349 (ISBN 978-1-59593-763-6, DOI 10.1145/1322263.1322295)
      Présentation de Chameleon et RIME
    • (en) Adam DUNKELS, « The ContikiMAC Radio Duty Cycling Protocol », SICS Technical Report,‎ , p. 1-11 (ISSN 1100-3154)
    • (en) Simon DUQUENNOY, Niklas WIRSTROM et Adam DUNKELS, « Snap - Rapid Sensornet Deployment with a Sensornet Appstore », SenSys '11 Proceedings of the 9th ACM Conference on Embedded Networked Sensor Systems,‎ , p. 316-332 (ISBN 978-1-4503-0718-5, DOI 10.1145/2070942.2071012)
    • (en) Mathilde DURVY, Julien ABEILLE, Patrick WETTERWALD, Colin O'FLYNN, Blake LEVERETT, Eric GNOSKE, Michael VIDALES, Geoff MULLIGAN, Nicolas TSIFTES, Niclas FINNE et Adam DUNKELS, « Making sensor networks IPv6 ready », SenSys '08 Proceedings of the 6th ACM conference on Embedded network sensor systems,‎ , p. 421-422 (ISBN 978-1-59593-990-6, DOI 10.1145/1460412.1460483)
      uIPv6 IPv6 Ready Phase-1
    • (en) Muhammad Omer FAROOQ et Thomas KUNTZ, « Operating Systems for Wireless Sensor Networks: A Survey », SENSORS,‎ , p. 5900-5930 (ISSN 1424-8220, DOI 10.3390/s110605900)
    • (en) M. FAZIO, M. PAONE, A. PULIAFITO et M. VILLARI, « Heterogeneous Sensors Become Homogeneous Things in Smart Cities », 2012 Sixth International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing,‎ , p. 775-780 (DOI 10.1109/IMIS.2012.136)
    • (en) Joao Miguel GONCALVES, « Dissertation submitted for obtaining the degree of », Master in Electronic Engineering,‎
    • (en) Lin GU et John A. STANKOVIC, « t-kernel: providing reliable OS support to wireless sensor networks », SenSys '06 Proceedings of the 4th international conference on Embedded networked sensor systems,‎ , p. 1-14 (ISBN 1-59593-343-3, DOI 10.1145/1182807.1182809)
      Three OS features: OS protection - virtual memory - preemptive scheduling
    • (en) Jiajie HE et Xiaohong HUANG, « Increased interoperability: Evolution of 6LoWPAN-based web application », Broadband Network and Multimedia Technology (IC-BNMT), 2011 4th IEEE International Conference - IEEE Conference Publications,‎ , p. 507-510 (DOI 10.1109/ICBNMT.2011.6155986)
    • (en) Mickael HEALY, Thomas NEWE et Elfer LEWIS, « Power Considerations When Using High Capacity Data Storage On Wireless Sensor Motes », IEEE SENSORS Conference 2009,‎ 20o9, p. 1415-1418 (DOI 10.1109/ICSENS.2009.5398434)
      La consommation Ă©lectrique des cartes SD
    • (en) Mohammad Sajjad HOSSAIN et Vijay RAGHUNATHAN, « AEGIS: a lightweight firewall for wireless sensor networks », DCOSS'10 Proceedings of the 6th IEEE international conference on Distributed Computing in Sensor Systems,‎ , p. 258-272 (ISBN 978-3-642-13650-4, DOI 10.1007/978-3-642-13651-1_19)
      pare-feu AEGIS
    • (en) Kim HYOSEUNG et Cha HOJUNG, « Multithreading optimization techniques for sensor network operating systems », EWSN'07 Proceedings of the 4th European conference on Wireless sensor networks,‎ , p. 293-308 (ISBN 978-3-540-69829-6)
    • (en) JeongGil KO et Nicolas TSIFTES, « Pragmatic Low-Power Interoperability:ContikiMAC vs TinyOS LPL », SENSOR,‎ , p. 94-96 (ISBN 978-1-4673-1904-1, ISSN 2155-5486, DOI 10.1109/SECON.2012.6276358)
    • (en) JeongGil KO, Joakim ERIKSSON, Nicolas TSIFTES, Stephen DAWSON-HAGGERTY, Jean-Philippe VASSEUR, Mathilde DURVY, Andreas TERZIS, Adam DUNKELS et David CULLER, « Beyond Interoperability – Pushing the Performance of Sensor Network IP Stacks », SenSys '11 Proceedings of the 9th ACM Conference on Embedded Networked Sensor Systems,‎ , p. 1-11 (ISBN 978-1-4503-0718-5, DOI 10.1145/2070942.2070944)
    • (en) Kevin Dominik KORTE, Anuj SEHGAL et JĂĽrgen SCHONWALDER, « A Study of the RPL Repair Process Using ContikiRPL », AIMS'12 Proceedings of the 6th IFIP WG 6.6 international autonomous infrastructure, management, and security conference on Dependable Networks and Services,‎ , p. 50-61 (ISBN 978-3-642-30632-7, DOI 10.1007/978-3-642-30633-4_8)
    • (en) Matthias KOVATSCH, Simon DUQUENNOY et Adam DUNKELS, « A Low-Power CoAP for Contiki », MASS '11 Proceedings of the 2011 IEEE Eighth International Conference on Mobile Ad-Hoc and Sensor Systems,‎ , p. 855-860 (ISBN 978-0-7695-4469-4, DOI 10.1109/MASS.2011.100)
    • (en) Rafael LAJARA, JosĂ© PELIGRI-SEBASTIA et Juan J. Perez SOLANO, « Power Consumption Analysis of Operating Systems for Wireless Sensor Networks », SENSORS,‎ , p. 5809-5826 (DOI 10.3390/s100605809)
    • (en) Philip LEVIS, « Demo: Experiences from a decade of TinyOS development integrated development environment », OSDI'12 Proceedings of the 10th USENIX conference on operating Systems Design and Implementation,‎ , p. 207-220 (ISBN 978-1-931971-96-6)
    • (en) Xing HE, Kun Mean HOU et Honglin SHI, « Efficient middleware for user-friendly wireless sensor network integrated development environment », Wireless Advanced (WiAd),‎ , p. 22-28 (DOI 10.1109/WiAd.2012.6296561)
    • (en) Luca MAINETTI, Luigi PATRONO et Antonio VILEI, « Evolution of Wireless Sensor Networks towards the Internet of Things: a Survey », IEEE Conference Publications,‎ , p. 1-6 (lire en ligne)
    • (en) Cintia MARGI, Marcos SIMPLICIO et Mats NASLUND, « Impact of Operating Systems on Wireless Sensor Networks », Computer Communications and Networks (ICCCN), 2010 Proceedings of 19th International Conference,‎ , p. 1-6 (DOI 10.1109/ICCCN.2010.5560028)
      Présentation de contiki lors de la 29e conférence annuelle de l'IEEE
    • (en) Hong MIN, Junyoung HEO, Yookun CHO, Kahyun LEE, Jaegi SON et Byunghun SONG, « A Module Management Scheme for Dynamic Reconfiguration », ICCSA '08 Proceeding sof the international conference on Computational Science and Its Applications, Part I,‎ , p. 820-828 (ISBN 978-3-540-69838-8, DOI 10.1007/978-3-540-69839-5_61)
    • (en) Mohamed MOUBARAK et Mohamed K. WATFA, « Embedded Operating Systems in Wireless Sensor Networks », Computer Communications and Networks,‎ , p. 323-346 (DOI 10.1007/978-1-84882-218-4_13)
    • (en) George OIKONOMOU et Iain Phillips, « Experiences from Porting the Contiki Operating System to a Popular Hardware Platform », Computer Science,‎ , p. 1-6 (DOI 10.1109/DCOSS.2011.5982222)
    • (en) Damien ROTH, Julien MONTAVONT et Thomas NOEL, « Performance evaluation of mobile IPv6 over 6LoWPAN », PE-WASUN '12 Proceedings of the 9th ACM symposium on Performance evaluation of wireless ad hoc, sensor, and ubiquitous networks,‎ , p. 77-84 (ISBN 978-1-4503-1621-7, DOI 10.1145/2387027.2387041)
      mobile IPv6 over 6LoWPAN
    • (en) Janos SALLAI, Miklos MAROTI et Akos LĂ©DECZI, « A concurrency abstraction for reliable sensor network applications », Proceedings of the 12th Monterey conference on Reliable systems on unreliable networked platforms,‎ , p. 143-160 (ISBN 978-3-540-71155-1)
    • (en) Lalit SARASWAT et Pankaj Singh YADAV, « A Comparative Analysis of Wireless Sensor Network Operating Systems », Techsci,‎ , p. 41-47 (lire en ligne)
    • (en) Shunsuke SARUWATARI, Makoto SUZUKI et Hiroyuki MORIKAWA, « PAVENET OS: A Compact Hard Real-Time Operating System for Precise Sampling inWireless Sensor Networks », SICE Journal of Control, Measurement, and System Integration,‎ , p. 024-033
    • (en) J. HILL, R. SZEWCZYK, A. WOO, S. HOLLAR, D. CULLER et K. PISTER, « System Architecture Directions for Network Sensors », Proc.Ninth Int’l Conf. Architectural Support for Programming Languages and Operating Systems,‎ , p. 93-104
    • (en) Nicolas TSIFTES, Adam DUNKELS, Thiemo VOIGT et Zhitao HE, « Enabling large-scale storage in sensor networks with the Coffee file system », Proceedings of the 2009 International Conference on Information Processing in Sensor Networks,‎ , p. 349-360 (ISBN 978-1-4244-5108-1)
      Présentation de Coffee file system lors d'une conférence des CPSWeek à San Francisco, Californie, USA
    • (en) Nicolas TSIFTES, Adam DUNKELS et Joakim ERIKSSON, « Low-power wireless IPv6 routing with ContikiRPL », Proceedings of the 9th ACM/IEEE International Conference on Information Processing in Sensor Networks,‎ , p. 406-407 (ISBN 978-1-60558-988-6, DOI 10.1145/1791212.1791277)
    • (en) Nicolas TSIFTES et Adam DUNKELS, « A database in every sensor », SenSys '11 Proceedings of the 9th ACM Conference on Embedded Networked Sensor Systems,‎ , p. 316-332 (ISBN 978-1-4503-0718-5, DOI 10.1145/2070942.2070974)
      Présentation de Antelope
    • (en) Lars WOLF, Ulf KULAU et Felix BUSCHING, « Demo: INGA: an inexpensive node for general applications integrated development environment », Proceedings of the 9th ACM Conference on Embedded Networked Sensor Systems,‎ , p. 435-436 (ISBN 978-1-4503-0718-5, DOI 10.1145/2070942.2071026)
    • (en) Domenico CAPUTO et Luca MAINETTI, « Implementation of the EXI schema on wireless sensor nodes using Contiki », IEEE Conference Publications,‎ , p. 770-774 (DOI 10.1109/IMIS.2012.79)
    • (en) BRUNO CAPUTO et Mirko FRANCESCHINIS, « 6LoWDTN: IPv6-Enabled Delay-Tolerant WSNs for Contiki », Distributed Computing in Sensor Systems and Workshops (DCOSS), 2011 International Conference on - IEEE Conference Publications,‎ , p. 1-6 (DOI 10.1109/DCOSS.2011.5982154)
    • (en) « Programming Language Popularity », (consultĂ© le )
    • (en) « TIOBE Programming Community Index », (consultĂ© le )
    • (en) « IETF RFC6550 », (consultĂ© le )
    • (en) « Constrained Application Protocol (CoAP) », (consultĂ© le )
    • (en) « HTTP Header Field Registrations », (consultĂ© le )
    • (en) « Code source apps », (consultĂ© le )
    • (en) « Contiki hardware », (consultĂ© le )
    • (en) « VMware Player download », (consultĂ© le )
    • (en) « Thingsquare news », (consultĂ© le )
    • (en) « Instant Contiki », (consultĂ© le )
    • (en) « European R&D projects », (consultĂ© le )
    • (en) « Lien sur le site RETOS » (consultĂ© le )
    • (en) « Le site de TinyOS » (consultĂ© le )
    • (en) « Le site de LiteOS » (consultĂ© le )
    • (en) « Le site de RECIM News - Environnement marin » (consultĂ© le )

    Liens externes

    Cet article est issu de wikipedia. Text licence: CC BY-SA 4.0, Des conditions supplémentaires peuvent s’appliquer aux fichiers multimédias.