Contiki

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

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

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

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

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

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

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

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

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

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

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.

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.

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.

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.

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.

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

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

• Le modèle de programmation supporté par un système d'exploitation a un impact significatif sur le développement d'applications. TinyOS, Contiki et LiteOS supporte le modèle d'exécution évènementiel[83] et multithreads. Mais il est précisé [88] que l'ordonnanceur évènementiel de Contiki, contrairement à celui de Mantis, est sans préemption.

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

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

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

• Le projet INGA utilise Contiki pour son réseau de capteurs sans fils de mouvement et de position. Les mesures de l'accéléromètre, du gyroscope et des capteurs de pression, détectent le mouvement et la position en temps réel avec une visualisation possible en 3D grâce à une transmission TCP/IPv6 sur connexion IEEE 802.15.4. Les premières applications se font dans le domaine de la santé pour la surveillance des personnes âgées, et dans le domaine de l'aéronautique (quadrocopters (en))[103].

• Le projet de SICS (en) pour contrôler l'environnement marin[104] met en œuvre un réseau de capteurs se servant de Contiki Coffee pour stocker une grande quantité de données et limiter ainsi des tâches trop consommatrices d'énergie.

• WiSMote mini [105], est un module qui embarque Contiki, dans le but de gérer et de traiter toutes sortes de grandeurs physiques dans les domaines de l'environnement, la santé, les compteurs intelligents, la domotique, la logistique ou les applications industrielles.

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

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

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

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

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

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