Aller au contenu

Contiki

Un article de Wikipédia, l'encyclopédie libre.
Article principal : Système d'exploitation pour capteur en réseau.
Page d’aide sur l’homonymie

Pour l’article ayant un titre homophone, voir Kon-Tiki.

Contiki
Capture d'écran de Contiki.
Capture d'écran de Contiki.
Plates-formes MultiplateformeVoir et modifier les données sur Wikidata
Entreprise /
Développeur 		Adam Dunkels (en)Voir et modifier les données sur Wikidata
Licence BSD 3-clausesVoir et modifier les données sur Wikidata
Dernière version stable 4.8 ()[1]Voir et modifier les données sur Wikidata
Site web www.contiki-os.orgVoir et modifier les données sur Wikidata
modifier 

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.

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

Fonctionnement et théorie

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

[modifier | modifier le code]

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

Empreinte mémoire

[modifier | modifier le code]

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

[modifier | modifier le code]

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

[modifier | modifier le code]

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é

[modifier | modifier le code]

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é

[modifier | modifier le code]

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

Des fonctionnalités

[modifier | modifier le code]

Accès distant

[modifier | modifier le code]
interface graphique de Contiki

Contiki propose plusieurs moyens de connexion à distance : [réf. nécessaire]

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

Autres

[modifier | modifier le code]

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

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

[modifier | modifier le code]

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

[modifier | modifier le code]

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

[modifier | modifier le code]

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

[modifier | modifier le code]

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

[modifier | modifier le code]

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

[modifier | modifier le code]

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

[modifier | modifier le code]
Article principal : Système d'exploitation pour capteur en réseau.

Présentation

[modifier | modifier le code]

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

Comparaison

[modifier | modifier le code]

Les caractéristiques

[modifier | modifier le code]

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

[modifier | modifier le code]
Article détaillé : TinyOS.

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

[modifier | modifier le code]

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

[modifier | modifier le code]

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. Aujourd'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 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

[modifier | modifier le code]

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’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

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

[modifier | modifier le code]

Notes

[modifier | modifier le code]

Références

[modifier | modifier le code]
  1. ↑ « https://github.com/contiki-ng/contiki-ng »
  2. ↑ a et b Farooq 2011, p. 5900
  3. ↑ Barton 2008, p. 105-125
  4. ↑ a et b Dunkels 2004, p. 455-462
  5. ↑ Farooq 2011, p. 5910
  6. ↑ Moubarak 2009, p. 336
  7. ↑ a b et c Farooq 2011, p. 5901
  8. ↑ Lajara 2010, p. 5819-5820
  9. ↑ Dunkels 2007, p. 7
  10. ↑ a et b Farooq 2011, p. 5911
  11. ↑ a b et c Dunkels 2006, p. 29-42
  12. ↑ Moubarak 2009, p. 335
  13. ↑ a et b IETF RFC RPL 2012
  14. ↑ Constrained Application Protocol (CoAP) 2012
  15. ↑ Tsiftes 2009, p. 449-460
  16. ↑ Farooq 2011, p. 5909
  17. ↑ a b c d et e Dunkels 2011, p. 1
  18. ↑ a et b 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. ↑ a et b Contiki hardware 2012
  29. ↑ Dunkels 2003, p. 85-98
  30. ↑ Dunkels 2003, p. 86
  31. ↑ a et b 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. ↑ a et b 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. ↑ a et b SOS
  65. ↑ MantisOS
  66. ↑ Nano-RK
  67. ↑ LiteOS
  68. ↑ RETOS
  69. ↑ a et b 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. ↑ a b c et d Chien 2011, p. 77
  84. ↑ a et b 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. ↑ a et b Thingsquare news 2012
  113. ↑ a et b 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

[modifier | modifier le code]
  • (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 )
v · m
Systèmes
Protocoles
Langages
Matériel
Logiciels
Applications
Protocoles de routage
Conférences et revues
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 ».

Liens externes

[modifier | modifier le code]
Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Contiki&oldid=219718668 ».