Vous êtes sur la page 1sur 18

Universit de Brest

Facult de Sciences et Technologie


Dpartement Informatique

Les Systme Embarqu


TinyOS

Ralis par : MEDJHOUM Khaled


Encadr par : BOUKHOUBZA Jalil

Sommaire
1.
2.

Introduction ........................................................................................................................ 1
Systme Embarqu TinyOS ............................................................................................... 3
2.1.
Proprits de TinyOS ................................................................................................. 3
2.2.
Primitives de TinyOS ................................................................................................. 3
2.2.1.
Gestion des processus......................................................................................... 4
2.2.2.
Gestion de la mmoire........................................................................................ 6
2.2.3.
Gestion des Entres/Sorties................................................................................ 8
2.2.4.
Gestion de la connectivit (Networking): .......................................................... 8
2.2.5.
Gestion des Interruptions ................................................................................... 8
2.3.
Package TinyOS ......................................................................................................... 8
2.4.
Structure logicielle ..................................................................................................... 9
3. Le langage de programmation NesC ................................................................................ 10
3.1.
Dveloppement......................................................................................................... 11
3.2.
Compilation.............................................................................................................. 13
4. Les architectures cibles de TinyOS .................................................................................. 13
5. Conclusion........................................................................................................................ 15

Systme Embarqu

1.

TinyOS

Introduction
Depuis longtemps, l'homme a toujours voulu "asservir" la machine pour faire le travail

sa place (Rptitivit, Tches fastidieuses, Environnement hostile, ...). Avec le


dveloppement qu'ont subit l'informatique et l'lectronique on a russi embarquer des
"calculateurs" dans presque tous les appareils de notre vie quotidienne. Avec la diversit de
ces appareils et la complexit de tels systmes, c'tait sduisant de vouloir profiter des
avantages qu'offre un systme d'exploitation.
Mais face aux nombreuses contraintes qui les systmes embarqus devront faire face
comme l'architecture matrielle (Type et Taille de la mmoire, type de "calculateurs",..)
rendait l'ide d'utiliser directement un GPOS inenvisageable (vous vous imaginez un
Windows dans un baladeurs MP3?!).
Les concepteurs de systmes d'exploitation, voulant appliquer le principe de
rutilisabilit, ont voulu "compacter" des GPOS existants pour pouvoir tre embarqus et ceci
en liminant tout ce qui n'tait plus ncessaire dans un systme embarqu (gestion de
l'affichage, bibliothques, utilitaires, ...). Ainsi de nombreux "petits" systmes ont vu le jour;
TinyOS, Embedded Linux, Windows CE, ...
Cela tait trs pratique et on les a utiliss presque partout, mais des portes leurs sont
restes fermes, les portes qui mnent aux domaines o le respect des contraintes de temps est
primordial. Ainsi nos petits systmes compacts taient bons, mais pas assez. Alors pour
palier cette insuffisance, on a conu des systmes embarqus temps-rel.
Parmi les domaines dutilisation des systmes embarqus on retrouve les rseaux de
capteurs qui sont des rseaux sans fil considrs comme un type spcial des rseaux ad hoc o
les noeuds de ce type de rseaux consistent en un grand nombre de capteurs capables de
recevoir et de transmettre des donnes environnementales d'une manire autonome. La
position de ces noeuds est indtermine. Ils sont disperss alatoirement travers une zone
gographique, appele champ de captage, qui dfinit le terrain d'intrt pour le phnomne
capt. Ces capteurs sont disposs dune alimentation autonome. Leur dure de vie est limite
par la dure de vie de leur batterie. Cette contrainte forte une influence majeure sur
lensemble des techniques mises en place pour le dploiement de tels rseaux. Cest pourquoi
il a fallu mettre en place un systme dexploitation spcialis pour fonctionner sur ce type de
rseau de capteurs tout en respectant ses contraintes.
TinyOS [1] est un systme dexploitation open-source spcialement conu pour les
applications embarques fonctionnant en rseaux et, en particulier, pour les rseaux de
1

Systme Embarqu

TinyOS

capteurs sans-fil. Initialement dvelopp au sein de luniversit 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 sen
servent afin de dvelopper et tester des protocoles, diffrents algorithmes, des scnarios de
dploiement.
Cette popularit est lie au fait que TinyOS fournit non seulement des outils de
dveloppement et de simulation aux dveloppeurs mais galement une solution permettant de
dvelopper rapidement des applications rpondant la diversit des caractristiques existantes
dun rseau lautre telles que le besoin de fiabilit dans les informations rcoltes, la qualit
de service du rseau ou encore aux capteurs mis en jeu. En outre, le domaine de lembarqu
impose de svres contraintes notamment en ce qui concerne lespace de stockage et lespace
mmoire allous au systme dexploitation et aux applications tournant dessus. TinyOS
rpond ce problme en gnrant une trs petite empreinte mmoire [2], celle-ci
correspondant la fusion du systme dexploitation et de lapplication excute. Enfin, en ce
qui concerne plus particulirement le domaine des rseaux de capteurs, les capteurs sont
souvent lorigine de la dtection dun phnomne et informe le rseau de son existence.
TinyOS propose ainsi un modle de programmation orient vnement. Cette section
dcrit TinyOS en commenant dans un premier temps par la description de son modle et des
principales notions associes celui-ci. Ensuite, nous dtaillerons le langage NesC utilis
pour limplmentation de TinyOS. Celui-ci est un langage orient composant sinspirant du C
classique.

Systme Embarqu

2.

Systme Embarqu TinyOS

2.1.

Proprits de TinyOS

TinyOS

TinyOS est bas sur quatre grandes proprits qui font que ce systme dexploitation
sadapte particulirement bien aux systmes faible ressources :

vnementiel : Le fonctionnement dun systme bas sur TinyOS sappuie sur la


gestion des vnements se produisant. Ainsi, lactivation de tches, leur interruption
ou encore la mise en veille du capteur seffectue lapparition dvnements, ceux-ci
ayant la plus forte priorit. Ce fonctionnement vnementiel eventdriven soppose au
fonctionnement dit temporel ou timedriven o les actions du systme sont gres par
une horloge donne.

Non premptif : Le caractre premptif dun systme dexploitation prcise si celui-ci


permet linterruption dune tche en cours. TinyOS ne gre pas ce mcanisme de
premption entre les tches mais donne la priorit aux interruptions matrielles. Ainsi,
les tches entre elles ne sinterrompent pas mais une interruption peut stopper
lexcution dune tche.

Pas de temps rel : Lorsquun systme est dit temps rel celui-ci gre des niveaux
de priorit dans ses tches permettant de respecter des chances donnes par son
environnement. Dans le cas dun systme strict, aucune chance ne tolre de
dpassement contrairement un systme temps rel mou. TinyOS se situe au-del de
ce second type car il nest pas prvu pour avoir un fonctionnement temps rel.

Consommation : TinyOS a t conu pour rduire au maximum la consommation en


nergie du capteur. Ainsi, lorsquaucune tche nest active, il se met automatiquement
en veille.

2.2.

Primitives de TinyOS
TinyOS est un systme dexploitation ddier pour les rseaux de capture qui sont

caractris par une limitation considrable des ressources ces pour quoi il est impratif quil
implmente des primitives aussi fine pour pouvoir grer et fonctionner correctement sur ces
rseaux :

Systme Embarqu

TinyOS

2.2.1. Gestion des processus


A) Ordonnancement
Nous allons dtailler le fonctionnement prcis de lordonnanceur TinyOS qui est au
coeur de la gestion des tches et des vnements du systme. Le choix dun ordonnanceur
dterminera le fonctionnement global du systme et le dotera de proprits prcises telles que
la capacit fonctionner en vnementiel. Un systme d'exploitation doit percevoir
l'coulement du temps pour prendre ses dcisions d'ordonnancement. Pour fournir au systme
d'exploitation une base de temps lmentaire, le systme se base sur une horloge matrielle
gnrant des vnements Ticks des intervalles rguliers. Ainsi, la rsolution de l'chelle du
temps est fonction de la frquence de l'horloge. Comme la prise en compte de cette horloge
est couteuse en traitements, la frquence n'est, en pratique, pas trs leve (de l'ordre de
diximes de milliseconde). Dans certains cas, le systme utilise un compteur externe ou
interne au processeur avec une rsolution plus leve (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 dfini lors de la conception
(ordonnancement hors-ligne), ou sur des priorits relatives entre les processus, ou en fonction
de l'ordre d'activation (ordonnancement enligne).
Lordonnanceur TinyOS comporte :

Deux niveaux de priorit (bas pour les tches, haut pour les vnements)

Une file dattente FIFO (disposant dune capacit de 7 places)


Les tches sont utilises pour effectuer la plupart des blocs dinstruction dune

application. A lappel dune tache, celle-ci va prendre place dans la file dattente de type pour
y tre excute. Comme nous lavons vu, il ny a pas de mcanisme de premption entre les
tches et une tache active sexcute en entier. Ce mode de fonctionnement permet de bannir
les oprations pouvant bloquer le systme (inter-blocage, famine, ). Par ailleurs, lorsque la
file dattente des taches est vide, le systme dexploitation met en veille le dispositif jusquau
lancement de la prochaine interruption (on retrouve le fonctionnement event-driven).
Les vnements sont prioritaires par rapport aux tches et peuvent interrompre la tache
en cours dexcution. Ils permettent de faire le lien entre les interruptions matrielles
(pression dun bouton, changement dtat dune entre, ) et les couches logicielles que
constituent les taches.
Par ailleurs, entre les tches, un niveau de priorit est dfini permettant de classer les
tches, tout en respectant la priorit des interruptions (ou vnements). Lors de larrive dune
4

Systme Embarqu

TinyOS

nouvelle tche, celle-ci sera place dans la file dattente en fonction de sa priorit (plus elle
est grande, plus le placement est proche de la sortie). Dans le cas ou la file dattente est pleine,
la tche dont la priorit est la plus faible est enleve de la FIFO.
B) Communication et Synchronisation
Les notions de synchronisation et de communication sont troitement lies et
l'existence de l'une ne peut s'envisager sans faire rfrence l'autre. En gnral, les processus
d'une application n'voluent pas de faon indpendante. La spcification 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
mcanismes offerts par le systme. Parmi les mcanismes existants pour les systme Linuxien
et spcialement TinyOS, on peut citer:

Communications par Messages: Pour viter les problmes lis l'excution en


parallle des processus et rsoudre les problmes que pose la synchronisation, le
mcanisme le plus simple est celui de la bote aux lettres ou BAL (gnralement
implmente avec une seule case mmoire ou avec plusieurs sous forme de file de
message ou "queue"). Les changes s'effectuent de faon indirecte, le message est
plac en mmoire par l'metteur et il est rcupr depuis cette case par le rcepteur.

Communication par zone commune: La faon la plus simple et la plus rapide de


transmettre des donnes est de ne pas en transmettre. Il suffit de disposer d'une zone
de mmoire commune dans laquelle seront disposes les donnes en libre accs. Le
problme que pose ce type de communication est surtout la synchronisation entre les
processus.
Concernant la synchronisation, le systme TinyOS fournit plusieurs outils, parmi

lesquels on cite:

Synchronisation par Rendez-vous:


Rendez-vous unilatral : Un rendez-vous unilatral est un point o un processus se
synchronise avec quelque chose d'externe, sans que l'agent extrieur ait besoin de se
synchroniser avec ce processus (lattente sur un recive).
Rendez-vous bilatral : Un rendez-vous bilatral peut tre considr comme un double
rendez-vous unilatral o les deux processus doivent se synchroniser avant de
continuer.

Synchronisation par vnements: le systme TinyOS utilisent le mcanisme de


drapeaux vnements (ou event flags) pour signaler aux processus qu'un vnement

Systme Embarqu

TinyOS

asynchrone (event) s'est produit. Le principe d'attente sur un vnement est


relativement simple. Si le drapeau correspondant est positionn lorsque arrive la
requte d'attente, la tche continue son excution. Si le drapeau est zro, le processus
est suspendu jusqu' ce que le drapeau soit positionn. Un processus peut attendre sur
plusieurs vnements. Pour cela, il existe deux manires d'attendre: une
synchronisation conjonctive fait reprendre le processus lorsque tous les vnements
signals ont eu lieu; une synchronisation disjonctive fait reprendre le processus
lorsque n'importe lequel des vnements signals a eu lieu.

Synchronisation par change de messages: deux tches synchronises par un


message dont le contenu est important (rsultat d'un traitement par exemple).

Exclusion mutuelle : utilise pour le contrle des ressources partages du systme.


L'exclusion mutuelle empche l'accs une donne, un composant, ou un
priphrique si celui-ci est utilis par un autre processus. Il existe plusieurs mthodes
pour assurer l'exclusion mutuelle: Masquage des interruptions, Variables verrous,
Smaphores, ...

2.2.2. Gestion de la mmoire


Il est important de prciser de quelle faon un systme dexploitation aborde la gestion
de la mmoire, dautant plus lorsque ce systme travaille dans un environnement aussi
restreint.
Dans un systme embarqu et/ou Temps Rel, l'allocation mmoire est gnralement
statique (une fois pour toute, au dbut du programme), cela l'avantage de ne pas avoir des
mauvaises surprises sur la disponibilit mmoire Memory Overflow et surtout, ne ncessite
pas d'implmenter des algorithmes d'allocation mmoire compliqus ncessitant beaucoup de
temps de calcul. Et ceci pour viter le dcalage temporel d l'allocation mmoire autant que
possible, mais ceci n'est pas vident vue que les systmes sont embarqus et dots d'une
mmoire rduite qui ne peut pas accueillir le systme et tous les programmes en mme temps.
TinyOS occupe un espace mmoire trs faible puisquil ne prend que 300 400 octets
dans sa distribution minimale. En plus de cela, il est ncessaire davoir 4 Ko de mmoire libre
qui se rpartissent de la faon suivante:

La pile : sert de mmoire temporaire au fonctionnement du systme notamment pour


lempilement et le dpilement des variables locales.

Les variables globales : rservent un espace mmoire pour le stockage de valeurs


pouvant tre accessible depuis des applications diffrentes.
6

Systme Embarqu

TinyOS

La mmoire libre : pour le reste du stockage temporaire.

Figure 1 : Structuration de la mmoire sous TinyOS


La gestion de la mmoire dans TinyOS possde de plus quelques proprits. Le
systme opte pour la flat memory (Considrer l'espace mmoire comme une seule et mme
zone) au dtriment de la protection vue que cette dernire engendre un surcot li la
vrification de chaque adresse accde par le programme. La solution dans un systme
centralis tait de doter le matriel d'un composant MMU (Memory Mangement Unit) qui
gre la protection mais comme il est gourmand en ressources, le systme TinyOS en est
dpourvu.
Comme la plupart des systmes embarqus, TinyOS ne possde pas de support de
stockage, il n'est pas possible d'implmenter une mmoire virtuelle. La mmoire virtuelle
introduit le problme de latence d la gestion des dfauts de pages. C'est pour a que dans
les systmes avec support de la mmoire virtuelle, on fournit gnralement des primitives
permettant de verrouiller des pages en mmoire (primitive mlock() dans le standard POSIX),
ainsi la page ne peut tre swappe sur disque jusqu' ce qu'on la dverrouille ou jusqu' la fin
du programme. Ainsi, il ny a pas dallocation dynamique de mmoire et pas de pointeurs de
fonctions. Bien sur cela simplifie grandement limplmentation. Par ailleurs, il nexiste pas de
mcanisme de protection de la mmoire sous TinyOS, ce qui rend le systme particulirement
vulnrable aux crashs et corruptions de la mmoire.

Systme Embarqu

TinyOS

2.2.3. Gestion des Entres/Sorties


Dans un systme embarqu, le matriel et le logiciel sont intiment lis, ainsi le
matriel et le logiciel ne son pas aussi facilement discernables. Comme le systme embarqu
TinyOS est conu de faon fonctionner sur un grand nombre d'architectures, on a conu ce
qu'on appelle la HAL (Hardware Adaptation Layer). Cette couche encapsule toutes les
fonctions dpendantes de l'architecture.
2.2.4. Gestion de la connectivit (Networking):
Le support de la connectivit dans les systmes embarqus est trs important car il leur
permet de communiquer facilement avec l'extrieur mais aussi de les grer, les mettre jour,
etc. distance! Sans oublier que parfois, la connectivit (communication) est la fonction
principale du systme tel que les rseaux de capteurs, Routeur, Tlphone Portable, PDA, etc.
TinyOS implmente de nombreux protocoles pour la communication rseaux et offre
aux utilisateurs une palette de protocole de routage (protocole de routage proactif, ractif et
hybride). Car le plus 70% des oprations excut par un capteur sont des routages de paqus.
2.2.5. Gestion des Interruptions
Dans un TinyOS, La gestion des interruptions est d'une grande importance.
L'interaction avec l'environnement se fait travers des interruptions. Le traitement d'une
interruption se fait l'aide d'une routine correspondante (ISR Intrrupt Service Routine). Le
systme TinyOS est aussi appel systmes pilots par interruptions (Interrupt Driven Systems)
car la grande partie du traitement se fait durant les ISRs et le systme passe la plupart de son
temps dans un mode basse-nergie. Pour rduire les temps de latence dus aux changements de
contexte (Tche Courante => ISR => Ancienne tche), on a essay de limiter le nombre
dinterruptions grs et aussi d'utiliser des masques dinterruption pour ne prendre en compte
que les interruptions urgentes, et laisser les autres interruptions pour plus tard, dans le cas o
plusieurs interruptions ont lieu.

2.3.

Package TinyOS
TinyOS est prvu pour fonctionner sur une multitude de plateformes, disponibles ds

linstallation. En effet, TinyOS peut tre install partir dun environnement Windows (2000
et XP) ou bien GNU/Linux (Red Hat essentiellement, mais dautres distributions sont
galement possibles).

Systme Embarqu

TinyOS

Deux principales versions de TinyOS sont disponibles : la version stable (v. 1.1.0) et
la version actuellement en cours de tests (v. 1.1.15); la premire prsente moins de risques
mais est nettement moins rcente. En outre, afin dinstaller la dernire version de test, il est
ncessaire de procder dabord linstallation de la version 1.1.0. Voici la procdure
dinstallation :

Sous Windows : un guide propose linstallation de tous les principaux outils


ncessaires au bon fonctionnement du systme, notamment Cygwin (couche
d'mulation de l'API Linux) qui permet davoir une interface Unix sous Windows. Le
JDK Java 1.4 de Sun est ncessaire afin deffectuer la procdure dinstallation.

Sous GNU/Linux : des packages RPM sont proposs au tlchargement, un guide


explique la marche suivre. Les distributions Linux ayant un autre gestionnaire de
paquet peuvent utiliser un programme (comme Alien ) pour installer les packages,
ou compiler directement partir des sources. Le JDK de IBM est ncessaire.
Par la suite, des packages supplmentaires peuvent tre ajouts en passant par le site

SourceForge, qui met disposition le code open source de TinyOS et d'un ensemble de
programmes ddis.

2.4.

Structure logicielle
Le systme d'exploitation TinyOS s'appuie sur le langage NesC. Celui-ci propose une

architecture base sur des composants, permettant de rduire considrablement la taille


mmoire du systme et de ses applications. Chaque composant correspond un lment
matriel (LEDs, timer,...) et peut tre rutilise dans diffrentes applications. Ces applications
sont des ensembles de composants rutilisables et portables associes dans un but prcis. Ces
applications sont des ensembles de composants associs dans un but prcis. Les composants
peuvent tre des concepts abstraits ou bien des interfaces logicielles aux entres-sorties
matrielles de la cible tudie (carte ou dispositif lectronique)
Chaque composant est tout d'abord constitue d'une frame. Elle contient l'tat interne du
composant. Il s'agit d'un espace mmoire rserve de taille fixe permettant au composant de
stocker les variables globales et les donnes qu'il utilise pour raliser ses fonctionnalits. Il
n'en existe qu'une seule par composant et celle-ci est alloue statiquement a la compilation.
L'implmentation de composants s'effectue en dclarant des taches, des commandes ou
des vnements qui permettent de faire appel aux fonctionnalits d'autres composants
auxquels ils sont lies :

Systme Embarqu

TinyOS

Les taches sont utilises pour effectuer la plupart des blocs d'instruction d'une
application.

Une commande permet l'excution d'une fonctionnalit dans un autre composant.

Les vnements permettent de faire le lien entre les interruptions matrielles (pression
d'un bouton, changement d'tat d'une entre,...) et les couches logicielles que
constituent les taches.

Figure 2: Schma des interactions internes au systme TinyOS

3.

Le langage de programmation NesC


Le systme dexploitation TinyOS sappuie sur le langage NesC. Celui-ci propose une

architecture base sur des composants, permettant de rduire considrablement la taille


mmoire du systme et de ses applications. Chaque composant correspond un lment
matriel (LEDs, timer, ADC ) et peut tre rutilis dans diffrentes applications. Ces
applications sont des ensembles de composants associs dans un but prcis. Les composants
peuvent tre des concepts abstraits ou bien des interfaces logicielles aux entres sorties
matrielles de la cible tudie (carte ou dispositif lectronique).
Les composants NesC prsentent des similarits avec des objets. Les tats sont
encapsuls et on peut y accder par des interfaces. En NesC, l'ensemble des composants et
leurs interactions sont fixs la compilation pour plus d'efficacit. Ce type de compilation

10

Systme Embarqu

TinyOS

permet d'optimiser l'application pour une excution plus performante. En langage objet, cette
phase est ralise lors de l'excution ce qui rend celle ci plus lente.

3.1.

Dveloppement
Les interfaces spcifient un ensemble de fonctions, appeles commandes, qui doivent

tre implmentes par le fournisseur de linterface et un ensemble de fonctions, appeles


vnements, qui doivent tre implmentes par lutilisateur de linterface. Afin de distinguer
les fonctions concernant un vnement de celles concernant une commande, les en-ttes des
fonctions sont prcds des mots-cls respectifs event ou command. Voici un exemple simple
dinterface :

De plus, comme il a t mentionn prcdemment, le modle mmoire fix par


TinyOS nautorise pas les pointeurs de fonctions. Afin de nanmoins proposer un mcanisme
alternatif, NesC utilise des interfaces paramtres. Celles-ci permettent lutilisateur de crer
un ensemble dinterfaces identiques et den slectionner une seule appeler grce un
identifiant.

Dans la pratique, NesC permet de dclarer deux types de fichiers: les modules et les
configurations.
Les configurations, permettent de dcrire les composants composites c'est--dire des
composants composs dautres composants cest dire de granularit suprieure. Une
configuration permet donc de dcrire larchitecture. Une configuration est donc constitue de
modules et/ou dinterfaces ainsi que de la description des liaisons entre ces composants.

11

Systme Embarqu

TinyOS

Dtaillons ici, quelques caractristiques concernant les configurations. La premire


dentre elles concerne une simplification. Lors du descriptif des liaisons, il est en effet
possible de ne pas prciser linterface fournie par un module. Dans ce cas, elle possdera le
mme nom que celle requise. Lautre caractristique concerne le composant Main. En effet, il
est noter que ce composant est obligatoirement prsent dans la configuration dcrivant
lensemble de lapplication car son rle est de dmarrer lexcution de lapplication.

Les modules sont eux les lments de base de la programmation. Ils permettent en
effet dimplmenter les composants et sont stocks dans un fichier possdant la structure
suivante :

12

Systme Embarqu

3.2.

TinyOS

Compilation
La premire tape de ce processus consiste compiler les fichiers ncessaires

lapplication et au systme dexploitation. Celle-ci est ralise via le compilateur NesC fourni
par TinyOS. Son rle est premirement de transformer les fichiers NesC en fichier C et
deuximement dy intgrer les fichiers du noyau de TinyOS. Ce qui permet dobtenir un
fichier source C unique. Une fois cette tape accomplie, il ne reste alors qu utiliser un
compilateur C traditionnel qui va utiliser le fichier prcdemment cr afin de gnrer une
application excutable. Celle-ci sera donc constitue par la fusion du systme
dexploitation et du code applicatif. Ces diffrentes phases peuvent tre synthtises comme
lillustre la figure 3.

Figure 3 : Etapes de compilation dune application sous TinyOS

4.

Les architectures cibles de TinyOS


Il existe de nombreuses cibles possibles pour ce systme dexploitation embarqu.

Malgr leurs diffrences, elles respectent toutes globalement la mme architecture base sur
un noyau central autour duquel sarticulent les diffrentes interfaces dentre/sortie, de
communication et dalimentation la figure suivante illustre un schma gnral dune
architecture cible pour TinyOS.

13

Systme Embarqu

TinyOS

Figure 4 : Schma gnral dune architecture cible pour TinyOS

On peut voir sur la figure 4 les diffrents composants qui constituent une architecture
cible par TinyOS. Pour tre plus prcis chaque groupe de composants possde son propre
rle :

Mote, processeur, RAM et Flash


On appelle gnralement Mote, la carte physique utilisant TinyOS pour fonctionner.

Celle-ci a pour coeur le bloc constitu du processeur et des mmoires RAM et Flash. Cet
ensemble est la base du calcul binaire et du stockage, la fois temporaire pour les donnes
et dfinitif pour le systme TinyOS.

Radio et antenne
TinyOS est prvu pour mettre en place des rseaux sans fils, les quipements tudis

sont donc gnralement quips dune radio ainsi que dune antenne afin de se connecter la
couche physique que constitue les missions hertziennes.

LED, interface, capteur


TinyOS est prvu pour mettre en place des rseaux de capteurs, on retrouve donc des

quipements bards de diffrents types de dtecteurs et autres entres.

Batterie
Comme tout dispositif embarqu, ils disposent dune alimentation autonome telle

quune batterie, et parfois dun panneau solaire pour permettre de recharger cette batterie, ce
qui lui permet dtre dispos dans un endroit parfois inaccessible.

14

Systme Embarqu

TinyOS

Cependant quelques diffrences existent suivant les fabricants. Chacun deux


dveloppe son type de dispositif. Avec des contraintes hardware aussi strictes dues aux
contraintes des systmes embarqus, la partie software doit tre la plus adapte possible, d' o
un lien trs fort entre ces deux parties.

5.

Conclusion
Le systme TinyOS est un systme embarqu, dvelopp par lUniversit de Berkeley,

ddi spcialement pour les rseaux de capteurs, qui prsente un environnement de calcul
particulier soumit a plusieurs contraintes tel que lnergie, lespace mmoire, etc.
TinyOS permet le dveloppement dapplication simplifi par la mise en relation de
composants cibles, tout en offrant des primitives ainsi que des bibliothques rseaux qui le
ronde complais. Il est class parmi les systmes temps rel mou, premptif, vnementiel.
TinyOS a un grand avenir dans les systmes embarqu garce ses qualits qui
sduisent plusieurs dveloppeurs qui participent dans son dveloppement vu quil est opensource.

15

Bibliographie & Site web


[1] - TinyOS Mission Statement. UC Berkeley, 2004. http://www.tinyos.net/special/mission

[2]- D. Gay, P. Levis, R. v. Behren, M. Welsh, E. Brewer et D. Culler. The NesC Language:
A Holistic Approach to Networked Embedded Systems. In Proceedings of Programming
Language Design and Implementation (PLDI), June 2003.

http ://fr.wikipedia.org/wiki/TinyOS/

http ://www.tinyos.net/

http ://fr.wikipedia.org/wiki/Rseau de capteurs sans-_l/