« Contiki » : différence entre les versions

Un article de Wikipédia, l'encyclopédie libre.
Navigation interactive dans l’historique
← Modification précédenteModification suivante →
Contenu supprimé Contenu ajouté
VisuelWikicode
Aucun résumé des modifications
Ligne 998 : Ligne 998 :
| mois =
| mois =
| pages = 323-346
| pages = 323-346
| doi = 10.1007/978-1-84882-218-4 13
| doi = 10.1007/978-1-84882-218-4_13
| commentaire =
| commentaire =
}}
}}

Version du 6 janvier 2013 à 18:13

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[1]. La miniaturisation des capteurs et leur prix relativement faible[2], permet d'imaginer des applications très variées dans les domaines scientifiques, militaires, industriels et domotiques[1]. Pour faciliter le développement de ces applications, une équipe du centre suédois de recherche scientifique SICS a créé Contiki[3]. Destiné a ê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.

Fonctionnement et Théorie

architecture de Contiki[1]

Écrit en langage C, Contiki est constitué d’un noyau, de librairies, d’un chargeur de programmes informatiques et d’un jeu de process[4]. Comme tous systèmes d'exploitations, sont rôle est de gérer les ressources physiques tel que le processeur, la mémoire, les périphériques informatiques (d'entrés/sorties)[5]. Il fournit ensuite aux applications informatiques des interfaces permettant d'utiliser ces ressources[5]. Conçu pour les modules de capteurs sans-fil miniature, il occupe peu d'espace en mémoire et permet une consommation électrique très faible. Contiki offre deux types de connectivité:

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

Pour économiser la mémoire, tout en fournissant un bon contrôle de flux dans le code, Contiki utilise un mécanisme appelé Protothreads[7]. Protothreads est un compromis entre la programmation événementielle et la programmation multi-threads[8]. Contiki gère les standards 6LoWPAN, RPL[9], CoAP[10]. Le système de fichier Coffee permet des opérations sur des fichiers stockés sur une mémoire flash externe[11]. 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 consomme 2 kilo octets de RAM et 40 kilo octets de ROM[12].

Consommation électrique

L'énergie électrique, souvent apportée par une batterie de piles, peut être problématique à renouveler[5]. Si des systèmes de captages, comme des éléments photovoltaïques, éoliennes, ou autres peuvent être utilisés dans certain 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[13]. La réduction de temps de transmission et de réception radio est primordial. Pour cela, le module radio est activé lorsque c'est nécessaire, est arrêté ou mis en veille le reste du temps[13]. Mais lorsque le module radio est arrêté, le capteur ne reçoit pas les messages qui lui sont destinés[13]. Un réveil périodique risque d'être inutile, et donc de consommer de l'énergie de façon inefficace[13]. Pour gérer cette problématique, Contiki propose par défaut ContikiMAC, un mécanisme conçu pour pour rester en communication avec le réseau efficacement, tout en permettant la mise hors tension du module radio 99% du temps [13]. D'autres techniques permettent de limiter le 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[14]. Dans certains cas, il peut être utile de stocker des informations dans une base de données locale au capteur, telle que Antelope[15], comme par exemple si le capteur doit envoyer en ensemble de mesures semblables à des résultats déjà envoyé à 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)[16].

Communications

Contiki implémente 2 mécanismes de communication:

  1. la couche de protocole Rime[17]. 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[18].
  2. la couche (en)uIP. Contiki implémente uIPv4 et uIPv6. (en)uIP supporte les protocoles IP, TCP, UDP et ICMP[19]. uIPv6 est la première implémentation d'IPv6 pour capteurs miniatures a avoir obtenu le label IPv6 Ready Phase-1[20], elle répond aux exigences de la RFC4229[21]. 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[22], 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 1280 octets[23]. 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[14] dans la couche uIPv6, une implémentation du protocole de routage RPL[24] (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 [25][26]. La plus part des constructeurs de microprocesseurs et micro-contrôleur fournissent un compilateur C afin de traduire un programme écrit en langage C vers le langage machine qui sera compris par le microprocesseur. Le portage de Contiki est effectué pour les plateformes suivantes[27]: exp5438, z1 , 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 (en)uIP et lwIP permettant d'implémenter le protocole IP sur les systèmes limités en ressources tel que les capteurs[28]. Jusque là, les capteurs utilisaient des protocoles de communication propriétaires ou alors des adaptation d'IP permettant le fonctionnement des applications mais sans offrir toutes les fonctionnalités du protocol IP[29][30]. Dès la présentation de Contiki en 2004, (en)uIP et lwIP étaient disponibles. De par ce fait, les applications exécutées sur Contiki pouvaient dialoguer vers n'importe quel matériel supportant le protocol IP. L'arrivé de IPv6 et uIPv6 sur Contiki apporte une nouvelle interopérabilité vers les matériels supportant ce protocol. 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[31]. 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[32].

Des fonctionnalités

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[33] 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 : connu pour être le navigateur web le plus léger du monde...
  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[34]

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é 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), les modules sont au format ELF qui est le format par défaut produit par le compilateur GCC, ou bien au format Compact ELF[35]. 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[36]. 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[37].
  2. Réduction de l'utilisation de la mémoire vive: Le fait de charger les programmes que en temps utile réduit l'utilisation de la mémoire[38].
  3. Simplifie 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[39].

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ée [45].

Contiki implémente un système de fichier ou filesystem nommé Coffee[46]. Coffee a l'avantage d'utiliser peu de RAM, son empreinte mémoire est inférieure à 200KB, 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[7]. 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. 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.

Sécurité des données et des transmissions

Exécution d'applications en temps réel

Contiki n'est pas un système d'exploitation permettant l'éxécution d'applications en temps réel[52]. 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.

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 outils permets au développeurs de tester les applications à moindre coût. Les capteurs supportés[53] à 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[54], téléchargeable sous la forme d'une machine virtuelle VMware. Cette machine virtuelle peut être lancée par VMware Player[55] 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 2010[56] [57] et celui de décembre 2011[58]recensent les principaux systèmes d'exploitation pour les réseau de capteurs sans fil: TinyOS[59],Contiki[60], SOS[61],Mantis OS[62], Nano-RK[63], LiteOS[64], RETOS[65], SenSpireOS[66], et en décrivent sommairement leurs caractéristiques.

L'état de l'art de mai 2011[67] s'interresse aux plus populaires. Y sont developpé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[68], Contiki[69], Mantis OS[70], Nano-RK[71], LiteOS[72].

Un grand nombre de système d'exploitation disponible est également sité dans l'article de 2011[73], mais ne sont détaillés et comparés uniquement les deux qui sont privilégiés par les développeurs, tinyOS et contiki, et le dernier arrivé sur le marché, LiteOS. Il est également souligné que Contiki est le 1° système d'exploitation pour capteur sans fils à établir une communication avec une pile TCP/IP (en)uIP. En 2008, contiki implémente uIPv6, la plus petite stack ipv6 au monde [74].

Le même choix se retrouve dans le document de 2010[75], 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[76] et Science Direct[77]. Les pourcentages sont de 81% pour TinyOS, 9% pour Contiki, 8% pour Mantis et de 2% pour les autres[78].

Enfin dans un article d'aôut 2012, on retrouve encore ce même 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 [79]:

Caractéristiques [80] des systèmes d'exploitation pour WSN référencés dans l'état de l'art de 2011[67]
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
Language Programmation nesC C C C LiteC++
File System Single level Coffee non non Hierarchical Unix-like
Reconfiguration oui oui non non oui
Débogage Distant oui non oui non oui

Comparaison

Les caractéristiques

En comparant les caractéristiques importantes [81]de TinyOS, Contiki et (en)LiteOS, il en ressort que Contiki et LiteOS, avec leurs systèmes dynamiques et modulaires sont contrairement à TinyOS, basés sur un système statique et monolytique, plus flexible 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'aôut 2012 [82].

  • Le système d'exploitation de Contiki, contrairement à TinyOS écrit en NesC ou celui de LiteOS écrit en LiteC++, est codé en language C ce qui le rend très portable[83]. L'article de Laraja [84] 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[85].
  • L'implémentation du mécanisme de multithreads est également différente puisque liteOS la gère nativement, TinyOS uniquement grâce à sa librairie TinyThreads, et contiki optient ce mode d'exécution soit par librairie , soit par protothreads[87]. Le protothread [7] de contiki réduit l'utilisation mémoire, au détriment de certaines fonctionnalités comme le maintien des variables locales[88].
  • La pile réseau de TinyOS est la plus légère, elle est basée sur le principe de messages pondérés, Active Message(AM. 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 (en)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[81].
  • Concalves [89] montre que les mécanismes de mise en veille sont implémentés différemment sur les quatres 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[90].
  • Concernant le mécanisme de mise à jour dynamique du logiciel, il est natif sur LiteOS et Contiki[81].

TinyOS / Contiki

Article détaillé : TinyOS.

Une expérimentation[91] 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[92][93] . Mais, l'article [94] 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é. Mais, si on recherche la flexibilité, c'est Contiki le bon choix.

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 suite à sa caractéristique majeure: la petite taille de sa pile uIP[95].

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

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[97][98].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[99].

Applications

Les applications WSN peuvent être réparties en deux catégories[100], celles basées sur les technologies IP comme Contiki, et les autres implémentant des standards WSN comme wirelessHart, ZigBee ou d'autres protocoles propriétaires.

  • 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 ((en)quadrocopters)[101].
  • Le projet de (en)SICS pour contrôler l'environnement marin[102] met en oeuvre 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[104] 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 délivrée.


Perspectives

La création de Thingsquare Mist[105], 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[105] facilite énormément le développement et le déploiement de l'Internet des objets. Thingsquare[106] 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[107]. Dans ce cadre , cette dernière a lancé le projet Calipso[108], 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.

Historique

2003

Presentation par Adam Dunkels de FULL TCP/IP sur une architecture 8 bits[109].

2004

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

Decembre 2007

Contiki 2.1

Juillet 2008

Contiki 2.2

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

Juin 2009

Contiki 2.3

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

Fevrier 2010

Contiki 2.4

Septembre 2011

Contiki 2.5

A Low-Power CoAP for Contiki[113].

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

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

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[106] qui fournit des logiciels open-source destinés à l'Internet des objets.

Octobre 2012

Commercialisation de Thingsquare Mist[116], 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. ↑ a b et c Farooq 2011, p. 5910
  2. ↑ Barton 2008, p. 105-125
  3. ↑ Dunkels 2004, p. 455-462
  4. ↑ Moubarak 2009, p. 336
  5. ↑ a b et c Farooq 2011, p. 5901
  6. ↑ Dunkels 2007, p. 7
  7. ↑ a b et c Dunkels 2006, p. 29-42 Erreur de référence : Balise <ref> incorrecte : le nom « Dunkels2006_29-42 » est défini plusieurs fois avec des contenus différents.
  8. ↑ Moubarak 2009, p. 335
  9. ↑ IETF RFC RPL 2012
  10. ↑ Constrained Application Protocol (CoAP) 2012
  11. ↑ Tsiftes 2009, p. 449-460
  12. ↑ Farooq 2011, p. 5909
  13. ↑ a b c d et e Dunkels 2011, p. 1
  14. ↑ a et b Tsiftes 2010, p. 406
  15. ↑ Tsiftes 2011, p. 316-329
  16. ↑ Tsiftes 2011, p. 316
  17. ↑ Dunkels 2007, p. 7-9
  18. ↑ Dunkels 2007, p. 4-7
  19. ↑ Farooq 2011, p. 5911
  20. ↑ Durvy 2008, p. 422
  21. ↑ IETF RFC 4229 2012
  22. ↑ Korte 2012, p. 50
  23. ↑ Roth 2012, p. 78
  24. ↑ IETF RFC RPL 2012
  25. ↑ TIOBE Programming Community Index
  26. ↑ Programming Language Popularity
  27. ↑ Contiki hardware 2012
  28. ↑ Dunkels 2003, p. 85-98
  29. ↑ Dunkels 2003, p. 86
  30. ↑ He 2011, p. 507
  31. ↑ He 2011, p. 508
  32. ↑ Ko 2011, p. 10
  33. ↑ Code source apps 2012
  34. ↑ Dunkels 2006, p. 19
  35. ↑ Dunkels 2006, p. 18
  36. ↑ Min 2008, p. 822
  37. ↑ Dunkels 2006, p. 16
  38. ↑ Dunkels 2006, p. 25
  39. ↑ Min 2008, p. 822
  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. ↑ Farooq 2011, p. 5912
  53. ↑ Contiki hardware 2012
  54. ↑ Instant Contiki 2012
  55. ↑ VMware Player download 2012
  56. ↑ Dong 2010, p. 519
  57. ↑ Saraswat 2010, p. 41-45
  58. ↑ Dong 2011, p. 1798-1799
  59. ↑ TinyOS
  60. ↑ Contiki
  61. ↑ SOS
  62. ↑ MantisOS
  63. ↑ Nano-RK
  64. ↑ LiteOS
  65. ↑ RETOS
  66. ↑ SOS
  67. ↑ a et b Farooq 2011, p. 5900-5930
  68. ↑ Farooq 2011, p. 5905-5909
  69. ↑ Farooq 2011, p. 5909-5913
  70. ↑ Farooq 2011, p. 5913-5917
  71. ↑ Farooq 2011, p. 5917-5921
  72. ↑ Farooq 2011, p. 5921-5924
  73. ↑ Chien 2011, p. 74
  74. ↑ Chien 2011, p. 76
  75. ↑ Lajara 2010, p. 5812-5814
  76. ↑ ACM
  77. ↑ ScienceDirect o
  78. ↑ Lajara 2010, p. 5812
  79. ↑ Carle 2012, p. 7
  80. ↑ Dong 2010, p. 522
  81. ↑ a b c et d Chien 2011, p. 77
  82. ↑ Carle 2012, p. 12
  83. ↑ Chien2011 2011, p. 76
  84. ↑ Lajara et 2010 p5824
  85. ↑ Levis 2012, p. 213
  86. ↑ Saraswat 2010, p. 45
  87. ↑ Chien 2011, p. 78
  88. ↑ Chu 2013, p. 139
  89. ↑ Goncalves 2011, p. 17
  90. ↑ Saraswat2010 2010, p. 45
  91. ↑ Margi et 2010 P1-6
  92. ↑ Lajara et 2010 p5809-5826
  93. ↑ Oikonomou et 2011 p1-6
  94. ↑ Carle 2012, p. 12
  95. ↑ Fazio 2012, p. 779
  96. ↑ Ko 2012, p. xx
  97. ↑ Liu 2012, p. 22
  98. ↑ Chien 2011, p. 73
  99. ↑ Fazio 2012, p. 775
  100. ↑ He 2011, p. 507
  101. ↑ Wolf 2011, p. 435-436
  102. ↑ ERCIM News - Environnement marin
  103. ↑ WismoteMini
  104. ↑ SicsNobel
  105. ↑ a et b Thingsquare news 2012
  106. ↑ a et b Thingsquare
  107. ↑ Coetzee 2011, p. 1
  108. ↑ Calipso
  109. ↑ Dunkels 2003
  110. ↑ Dunkels 2004, p. 455-462
  111. ↑ Durvy 2008, p. 421-422
  112. ↑ Casado 2009, p. 147
  113. ↑ Kovatsch 2011, p. 855-860
  114. ↑ Tsiftes 2010, p. 406-407
  115. ↑ Dunkels 2011
  116. ↑ 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) 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) 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) 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,‎ 2o11, 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) 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) 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) 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, « 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, 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) Mickael HEALY 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) 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) 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.138)
    Présentation de contiki lors de la 29ème 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 4ème conférence ACM sur les système de capteurs en réseau, à Boulder, Colorado, USA
  • (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) 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) 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) 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) 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) C.C. HAN, R. KUMAR, R. SHEA, E. KOHLER et M.B. SRIVASTAVA, « A dynamic operating system for sensor nodes », Proceedings of the 3rd International Conference on Mobile Systems, Applications,

and Services (MobiSys’05),‎ , p. 163-176

  • (en) S. BHATTI, J. CARLSON, H. DAI, J. DENG, J. ROSE, A. SHETH, B. SHUCKER, C. GRUENWALD, A. TORGERSON et R. HAN, « MANTIS OS : An embedded multithreaded operating system for wireless micro sensor platforms », ACM Mobile Networks & Applications (MONET),,‎ , p. 563-579
  • (en) A. ESWARAN, A. ROWE et R. RADJKUMAR, « Nano-RK: An energyaware resource-centric RTOS for sensor networks », Proceedings of the 26th Real-Time Systems Symposium (RTSS’05),‎ , p. 256-265
  • (en) S. YI, H. MIN, S. LEE, Y. KIM et Y. JEONG, « SESAME: Space Efficient Stack Allocation Mechanism for Multithreaded Sensor Operating Systems », Proc. 22nd Symp. Applied Computing,‎ , p. 1201-1202
  • (en) Q. CAO, T.F. ABDELZAHER et J.A. STANKOVIC, « The LiteOS Operating System: Towards Unix-Like Abstractions for Wireless Sensor Networks », Seventh Int’l Conf. Information Processing in Sensor Networks,‎ , p. 233-244
  • (en) H. CHA, S. CHOI, I. JUNG, H. KIM et H. SHIN, « RETOS: Resilient,Expandable, and Threaded Operating System for Wireless Sensor Networks », Sixth Int’l Conf. Information Processing in Sensor Networks,‎
  • (en) K. LORINCZ, B. RONG CHEN, J. WATERMANN, G. WERNER-ALLEN et M. WELSCH, « Resource Aware Programming in the Pixie OS », Sixth ACM Conf. Embedded Network Sensor Systems (SenSys),‎
  • (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,‎ , p. 1788-1801
  • (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) 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)
  • (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) 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) Lalit SARASWAT et Pankaj Singh YADAV, « A Comparative Analysis of Wireless Sensor Network Operating Systems », Techsci,‎ , p. 41-47
  • (en) Rafael LAJARA et José SOLANO, « Power Consumption Analysis of Operating Systems for Wireless Sensor Networks », SENSORS,‎ , p. 5809-5826 (DOI 10.3390/s100605809)
  • (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)
    Proceedings of the Seminar Sensor Nodes – Operation, Network and Application (SN) Technische Universität München -Summer Semester 2012 -
  • (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) 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) Adam DUNKELS, « The ContikiMAC Radio Duty Cycling Protocol », SICS Technical Report,‎ , p. 1-11 (ISSN 1100-3154)
  • (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) 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) 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) Joao Miguel GONCALVES, « Dissertation submitted for obtaining the degree of », Master in Electronic Engineering,‎
  • (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 29ème conférence annuelle de l'IEEE
  • (en) Wei Dong, Chun Chen, Xue Liu et Jiajun Bu, « Providing OS Support for Wireless Sensor Networks: Challenges and Approaches », IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 12, NO. 4, FOURTH QUARTER 2010,‎ , p. 519-530 (DOI 10.1109/SURV.2010.032610.00045, lire en ligne)
  • (en) 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) 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,‎ , p. 507-510 (DOI 10.1109/ICBNMT.2011.6155986)
  • (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) 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) 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) « 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 )

Liens externes

Si ce bandeau n'est plus pertinent, retirez-le. Cliquez ici pour en savoir plus.
Si ce bandeau n'est plus pertinent, retirez-le. Cliquez ici pour en savoir plus.

Cet article ou cette section contient trop de liens externes (indiquez la date de pose grâce au paramètre date).

Les liens externes doivent être des sites de référence dans le domaine du sujet. Il est souhaitable — si cela présente un intérêt — de citer ces liens comme source et de les enlever du corps de l'article ou de la section « Liens externes ».

Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Contiki&oldid=87338402 ».