Sommaire 1. Introduction 2. Système Embarqué TinyOS — 2. 1. propriétés de TinyOS 2-2. Primitives de Ti nyos. • 3 2. 2. 1. Gestion des processus. • • • 2. 2. 2. Gestion de la mémoire….. . 2. 2. 3. Gestion des En or 18 Sorties… Sni* to View 2. 2. 4. Gestion de la c (Networking): 2. 2. 5. Gestion des Interruptions 7 2. 3. Package TinyOS. 7 2. 4. Structure logicielle . 3. Le langage de programmation NesC.. 3. 1. Développement…. 9 3*2. Compilation. 4. es architectures cibles de 11 5. Conclusion. …. …. 12 « asservir » la machine pour faire le travail à sa place (Répétitivité,
Tâches fastidieuses, Environnement hostile, Avec le développement qu’ont subit l’informatique et l’électronique on a réussl à embarquer des « calculateurs dans presque tous les appareils de notre vie quotidienne. Avec la diversité de ces appareils et la complexité de tels systèmes, c’était séduisant de vouloir profiter des avantages qu’offre un système d’exploitation. Mais face aux nombreuses contraintes à qui les systèmes embarqués devront faire face comme l’architecture matérielle (Type et Taille de la mémoire, type de « calculateurs »,.. ) rendait l’idée d’utiliser directement un GPOS inenvisageable (vous vous
Imaginez un Windows dans un baladeurs MP3?! ). Les concepteurs de systèmes d’exploitation, voulant appliquer le principe de réutilisabilité, ont voulu « compacter » des GPOS existants pour pouvoir être embarqués et ceci en éliminant tout ce qui n’était plus nécessaire dans un système embarqué (gestion de l’affichage, bibliothèques, utilitaires, Ainsi de nombreux « petits » systèmes ont vu le jou ; TinyOS, Embedded Linux. Windows CE, . Cela était très pratique et on les a utilisés presque partout, mais des portes leurs sont restées fermées, les portes qui mènent aux omaines où le respect des contraintes de temps est primordial.
Ainsi nos petits systèmes compactés étaient bons, mais pas assez. Alors pour palier à cette insuffisance, on a conçu des systèmes embarqués temps-réel. Parmi les domaines d’utilisation des systèmes embarqués on retrouve les reseaux de capteurs qui sont des réseaux sans fil considérés comme un type spécial des réseaux ad hoc où les noeuds de ce type de réseaux consisten 18 comme un type spécial des réseaux ad hoc où les noeuds de ce type de réseaux consistent en un grand nombre de capteurs capables derecevoir et de transmettre des données nvironnementales d’une manière autonome.
La position de ces noeuds est indéterminée. Ils sont dispersés aléatoirement à travers une zone géographique, appelée champ de captage, qui définit le terrain d’intérêt pour le phénomène capté. Ces capteurs sont disposés d’une alimentation autonome. Leur durée de vie est limitée par la durée de vie de leur batterie. Cette contrainte forte à une influence majeure sur l’ensemble des techniques mises en place pour le déploiement de tels réseaux. C’est pourquoi il a fallu mettre en place un système d’explo’tation pécialisé pour fonctionner sur ce type de réseau de capteurs tout en respectant ses contraintes.
TinyOS [Il est un système d’exploitation open-source spécialement conçu pour les applications embarquées fonctionnant en réseaux et, en particulier, pour les réseaux de capteurs sans-fil. Initialement développé au sein de l’université de Berkeley en Californie, TinyOS est devenu le standard de facto. En effet, celui-ci est installé sur tous les motes disponibles actuellement et de nombreux groupes de recherche ainsi que des industriels s’en servent afin de développer et tester des rotocoles, différents algorithmes, des scénarios de déploiement.
Cette popularité est liée au fait que TinyOS fournit non seulement des outils de développement et de simulation aux développeurs mais également une solution permettant de développer rapidement des applications répondant à la diversité des caractéristiques existantes d’un réseau à l’autre telles que le besoin de fiabilité dans les inf caractéristiques existantes d’un réseau à l’autre telles que le besoin de fiabilité dans les informations récoltées, la qualité de service du réseau ou encore aux capteurs mis en jeu.
En outre, le domaine de l’embarqué impose de sévères contraintes notamment en ce qui concerne [‘espace de stockage et [‘espace mémoire alloués au système d’exploitation et aux applications tournant dessus. TinyOS répond à ce problème en générant une très petite empreinte mémoire [2], celle-cicorrespondant ? la fusion du système d’exploitation et de l’application exécutée. Enfin, en ce qui concerne plus particulièrement le domaine des réseaux de capteurs, les capteurs sont souvent à l’origine de la détection d’un phénomène et informe le réseau de son existence.
TinyOS propose ainsi un modèle de programmation orienté évènement. Cette section décrit TinyOS en commençant dans un premier temps par la description de son modèle et des principales notions associées à celui-ci. Ensuite, nous détaillerons le langage Nesc utilisé pour l’implémentation de TinyOS. Celui-ci est un langage orienté composant s’inspirant du C classique. 2. Système Embarqué TinyOS TinyOS est basé sur quatre grandes propriétés qui font que ce système d’exploitation s’adapte particulièrement bien aux systèmes à faible ressources : : Le fonctionnement d’un système basé sur
TinyOS s’appuie sur la gestion des évènements se produisant. Ainsi, l’activation de tâches, leur interruption ou encore la mise en veille du capteur s’effectue à l’apparition d’évènements, ceux- ci ayant la plus forte priorité. Ce fonctionnement évènementiel eventdriven s’oppose au fonctionnement dit temporel ou timedriven où 8 fonctionnement évenementiel eventdriven s’oppose au fonctionnement dit temporel ou timedriven où les actions du système sont gérées par une horloge donnée. CIONon préemptif : Le caractère préemptif d’un système d’exploitation précise si celui-ci permet l’interruption d’une tâche n cours.
TinyOS ne gère pas ce mécanisme de préemption entre les tâches mais donne la priorité aux interruptions matérielles. Ainsi, les tâches entre elles ne s’interrompent pas mais une interruption peut stopper l’exécution d’une tâche. DÜPas de temps réel : Lorsqu’un système est dit « temps réel » celui-ci gère des niveaux de priorité dans ses tâches permettant de respecter des échéances données par son environnement. Dans le cas d’un système strict, aucune échéance ne tolère de dépassement contrairement à un système temps réel mou.
TinyOS se situe au-delà de ce second type car il n’est pas prévu pour avoir un fonctionnement temps réel. OTonsommation: inyOS a été conçu pour réduire au maximum la consommation en énergie du capteur. Ainsi, lorsqu’aucune tâche n’est active, il se met automatiquement en veille. 2. 2. Primitives de TlnyOS TinyOS est un système d’exploitation dédier pour les réseaux de capture qui sont caractérisé par une limitation considérable des ressources c’es pour quoi il est impératif qu’il implémente des primitives aussi fine pour pouvoir gérer et fonctionner correctement sur ces réseaux : 2. . . Gestion des processus A) Ordonnancement Nous allons détailler le fonctionnement précis de l’ordonnanceur TinyOS qui est au cœur de la gestion des tâches et des évènements du système. Le choix d’un ordonnanceur déterminera le fonctionnement global du système et le dotera de prop PAGF s 8 ordonnanceur déterminera le fonctionnement global du système et le dotera de propriétés précises telles que la capacité ? fonctionner en évènementiel. Un système d’exploitation doit percevoir l’écoulement du temps pour prendre ses décisions d’ordonnancement.
Pour fournir au système d’exploitation une ase de temps élémentaire, le système se base sur une horloge matérielle générant des événements Ticks à des intervalles réguliers. Ainsi, la résolution de l’échelle du temps est fonction de la fréquence de l’horloge. Comme la prise en compte de cette horloge est couteuse en traitements, la fréquence n’est, en pratique, pas très élevée (de l’ordre de dixièmes de milliseconde). Dans certains cas, le système utilise un compteur externe ou interne au processeur avec une résolution plus élevée (allant jusqu’à l’ordre des fractions de nanoseconde selon le type du capteur).
Cette fonctionnalité permet une prise en compte plus fine des contraintes temporelles. L’ordonnanceur peut reposer sur un calendrier ou un plan défini lors de la conception (ordonnancement hors-ligne), ou sur des priorités relatives entre les processus, ou en fonction de l’ordre d’activation (ordonnancement enligne). L’ordonnanceur TinyOS comporte : CIODeux niveaux de priorité (bas pour les tâches, haut pour les évènements) noune file d’attente FIFO (disposant dune capacité de 7 places) Les tâches sont utilisées pour effectuer la plupart des blocs d’instruction d’une application.
A l’appel d’une tache, celle-ci va prendre place dans la file d’attente de type pour y être exécutée. Comme nous l’avons vu, il n’y a pas de mecanisme de preemption entre les tâches et une tache activée s’exécute en entier. Ce mode de fonctionnem 6 8 préemption entre les tâches et une tache activée s’exécute en entier. Ce mode de fonctionnement permet de bannir les opérations pouvant bloquer le système (inter-blocage, famine, par ailleurs, lorsque la file d’attente des taches est vide, le système d’exploitation met en veille le dispositif jusqu’au lancement de la prochaine interruption (on retrouve le onctionnement event-driven).
Les évènements sont prioritaires par rapport aux tâches et peuvent interrompre la tache en cours d’exécution. Ils permettent de faire le lien entre les interruptions matérielles (pression d’un bouton, changement d’état d’une entrée, et les couches logicielles que constituent les taches. par ailleurs, entre les tâches, un niveau de priorité est défini permettant de classer les tâches, tout en respectant la priorité des interruptions (ou évènements).
Lors de l’arrivée dune nouvelle tâche, celle-ci sera placée dans la file d’attente en onction de sa priorité (plus elle est grande, plus le placement est proche de la sortie). Dans le cas ou la file d’attente est pleine, la tâche dont la priorité est la plus faible est enlevée de la FIFO. B) Communication et Synchronisation Les notions de synchronisation et de communication sont étroitement liées et l’existence de l’une ne peut s’envisager sans faire référence à l’autre.
En général, les processus d’une application n’évoluent pas de façon indépendante. La spécification de l’application fixe les relations logiques et temporelles entre ses processus. Dans le but de synchroniser ces processus, on fait communiquer ces processus à l’aide de mécanismes offerts par le système. Parmi les mécanismes existants pour les système linuxien et spécialement TinyOS, 7 8 offerts par le système. Parmi les mécanismes existants pour les système linuxien et spécialement TinyOS, on peut citer.
DOCommunications par Messages: Pour éviter les problèmes liés à l’exécution en parallèle des processus et résoudre les problèmes que pose la synchronisation, le mécanisme le plus simple est celui de la boite aux lettres ou BAL (généralement mplémentée avec une seule case mémoire ou avec plusieurs sous forme de file de message ou « queue »). Les échanges s’effectuent de façon indirecte, le message est placé en mémoire par l’émetteur et il est récupéré depuis cette case par le récepteur. DOCommunication par zone commune: La façon la plus simple et la plus rapide de transmettre des donnees est de ne pas en transmettre.
Il suffit de disposer d’une zone de mémoire commune dans laquelle seront disposées les données en libre accès. e problème que pose ce type de communication est surtout la synchronisation entre les processus. Concernant la synchronisation, le système TinyOS fournit plusieurs outils, parmi lesquels on cite: DÜSynchronisation par Rendez-vous: Rendez-vous unilatéral : Un rendez-vous unilatéral est un point où un processus se synchronise avec quelque chose d’externe, sans que l’agent extérieur ait besoin de se synchroniser avec ce processus (l’attente sur un recive).
Rendez-vous bilatéral: Un rendez-vous bilatéral peut être considéré comme un double rendez-vous unilatéral où les deux processus doivent se synchroniser avant de continuer. ClCSynchronisation par événements: le système TinyOS utilisent e mécanisme de drapeaux événements (ou event flags) pour signaler aux processus qu’un événement asynchrone (event) s’est produit. Le prlncipe d’attente sur 8 processus qu’un événement asynchrone (event) s’est produit. Le principe d’attente sur un événement est relativement simple.
Si le drapeau correspondant est positionné lorsqu’arrive la requête d’attente, la tâche continue son exécution. Si le drapeau est à zéro, le processus est suspendu jusqu’à ce que le drapeau soit positionné. un processus peut attendre sur plusieurs événements. Pour cela, il existe deux manières d’attendre: une ynchronisation conjonctive fait reprendre le processus lorsque tous les événements signalés ont eu lieu; une synchronisation disjonctive fait reprendre le processus lorsque n’importe lequel des événements signalés a eu lieu.
DÜSynchronisation par échange de messages: deux tâches synchronisées par un message dont le contenu est important (résultat d’un traitement par exemple). Exclusion mutuelle : utilisée pour le contrôle des ressources partagées du système. L’exclusion mutuelle empêche l’accès à une donnée, à un composant, ou à un périphérique si celui-ci est utilisé par un utre processus. Il existe plusieurs méthodes pour assurer l’exclusion mutuelle: Masquage des interruptions, Variables verrous, Sémaphores, „ 2. . 2. Gestion de la mémoire Il est important de préciser de quelle façon un système d’exploitation aborde la gestion de la mémoire, d’autant plus lorsque ce système travaille dans un environnement aussi restreint. Dans un système embarqué et/ou Temps Réel, l’allocation mémoire est généralement statique (une fois pour toute, au début du programme), cela à l’avantage de ne pas avoir des mauvaises surprises sur la disponibilité mémoire Memory
Overflow et surtout, ne nécessite pas d’implémenter des algorithmes d’allocation mémoire compliq PAGF 18 algorithmes d’allocation mémoire compliqués nécessitant beaucoup de temps de calcul. Et ceci pour éviter le décalage temporel dû à l’allocation mémolre autant que posslble, mais cecl n’est pas évident vue que les systèmes sont embarqués et dotés d’une mémoire réduite qui ne peut pas accueillir le système et tous les programmes en même temps. TinyOS occupe un espace mémoire très faible puisqu’il ne prend que 300 à 400 octets dans sa distribution minimale.
En plus de cela, il est nécessaire d’avoir 4 Ko de mémoire libre qui se répartissent de la façon suivante: DOI_a pile : sert de mémoire temporaire au fonctionnement du système notamment pour l’empilement et le dépilement des variables locales. Les variables globales : réservent un espace mémoire pour le stockage de valeurs pouvant être accessible depuis des applications différentes. DÜLa mémoire libre : pour le reste du stockage temporaire. Figure 1 : Structuration de la mémoire sous TinyOS La gestlon de la mémoire dans TlnyOS possède de plus quelques propriétés.
Lesystème opte pour a flat memory (Considérer l’espace mémoire comme une seule et même zone) au détriment de la protection vue que cette dernière engendre un surcoût lié à la vérification de chaque adresse accédée par le programme. La solution dans un système centralisé était de doter le matériel d’un composant MMIJ (Memory Mangement Unit) qui gère la protection mais comme il est gourmand en ressources, le système TinyOS en est dépouNu. Comme la plupart des systèmes embarqués, TinyOS ne possède pas de support de stockage, il n’est pas possible d’implémenter une memo
