Systeme d'exploitation pour reseaux de capteur sans fils

1. LE SYSTÈME D'EXPLOITATION POUR RCSF : TINYOS

2. INTRODUCTION

3. POURQUOI UN NOUVEAU OS POUR LES « MOTES » ?
1- Caractéristiques des OS classiques :
Les OS classiques sont généralement conçus pour un usage générique. Ils sont ainsi conçus en
supposant une disponibilité sans limite des ressources. Leur objectif est la facilité d'usage, la
rapidité et efficacité. Parmis leurs caractéristiques, on peut citer:
 Architecture Multi-thread=>Mémoire importante
 Modèle E/S
 Séparation entre espace noyau et utilisateur
 Pas de contraintes d'énérgie
 Ressources disponibles

4. Les OS classiques ne sont pas appropriés aux "motes" (noeuds capteurs), vus que ces derniers
sont caractérisés par :
 Ressources énergétiques basses
 Mémoire limitée
 CPU lente
 Petite taille
 Parallélisme matériel limité
 Communication radio
 Bande-passante faible
 Portée radio courte
2- Contraintes d'un "mote"

5. PROPRIÉTÉS DE L'OS SOUHAITÉ POUR LES "MOTES"
 Image mémoire petite
 Efficacité en calcul et consommation d'énergie
 La communication est fondamentale
 Temps-réel
 Construction efficace d'applications

6. LA SOLUTION TINYOS
1- Caractéristiques de TinyOS
• Concurrence : utilise une architecture orientée événement
• Modularité
 Application composée de composants
 OS + Application compilés en un seul exécutable
• Communication
 Utilise un modèle event/command
 Ordonnancement FIFO non préemptif
• Pas de séparation noyau/utilisateur

7. APERÇUS GÉNÉRALE DE TINYOS
 Système d'exploitation pour réseaux de capteurs embarqués
 Ensemble de composants logiciels qui peuvent être reliés ensemble en un seul exécutable sur un mote
 Fonctions minimales
 Deux threads: tâches et handlers
d'événements matériels
 Pas de gestion de la mémoire...

8. MODÈLE MÉMOIRE DE TINYOS
 Allocation statique de la mémoire
 Pas de heap (malloc)
 Pas de pointeur sur function
 Pas d'allocation dynamique
 Variables globales
 Disponibles per-frame
 Conservation de la mémoire
 Utilisation de pointeurs
 Variables locales
 Sauvegardées sur la pile (stack)
 Déclarées dans une méthode

9.  Le système d’exploitation TinyOS s’appuie sur le langage NesC. Celui-ci propose une architecture basée
sur des composants, permettant de réduire considérablement la taille mémoire du système et de ses
applications. Chaque composant correspond à un élément matériel (LEDs, timer, ADC…) et peut être
réutilisé dans différentes applications. Ces applications sont des ensembles de composants associés dans
un but précis. Les composants peuvent ,,,
 L’implémentation de composants s’effectue en déclarant des tâches, des commandes ou des
évènements.
 Une tâche est un travail de « longue durée ».
 Une commande est l'exécution d’une fonctionnalité précise dans un autre composant.
 Un événement est l'équivalent logiciel à une interruption matérielle.

10.  Il existe de nombreuses cibles possibles pour ce système d’exploitation embarqué. Malgré leurs différences,
elles respectent toutes globalement la même architecture basée sur un noyau central autour duquel s’articule
les différentes interfaces d’entrée-sortie, de communication et d’alimentation. Voici un schéma représentant
cette architecture :
 Mote, processeur, RAM et Flash : On appelle généralement Mote la carte physique utilisant TinyOS pour
fonctionner. Celle-ci a pour cœur le bloc constitué du processeur et des mémoires RAM et Flash. Cet ensemble
est à la base du calcul binaire et du stockage, à la fois temporaire pour les données et définitif pour le système
TinyOS.
 Radio et antenne : TinyOS est prévu pour mettre en place des réseaux sans fils, les équipements étudiés sont
sont donc généralement équipés d’une radio ainsi que d’une antenne afin de se connecter à la couche
physique que constitue les émissions hertziennes.
 LED, interface, capteur : TinyOS est prévu pour mettre en place des réseaux de capteurs, on retrouve donc
des équipements bardés de différents types de détecteurs et autres entrées.
 Batterie : Comme tout dispositif embarqué, ceux utilisant TinyOS sont pourvus d’une alimentation autonome
autonome telle qu’une batterie.

11. Au-delà de cette liste, il est possible d’implémenter tout type de plateforme embarquée physique en redéveloppant les
bibliothèques nécessaires à la prise en compte des entrées sorties nécessaires.

12. ALLOCATION DES RESSOURCES
L’ordonnanceur:
Le choix d’un ordonnanceur d´extermine le fonctionnement global du système et le dote de propriétés telles
que la capacite a fonctionner en temps réel.
L’ordonnanceur TinyOS se compose de :
– 2 niveaux de priorités (bas pour les tâches, haut pour les évènements).
– 1 file d’attente FIFO
Il existe trois approches algorithmiques pour l’ordonnancement d’activité

13. ALLOCATION DES RESSOURCES
Tâche
Une tâche est un travail de « longue durée »,elle est utilisé pour effectuer la plupart des blocs d’instruction
d’une application. À l’appel d’une tâche, celle-ci va prendre place dans une file d’attente de type FIFO (First In
First Out) pour y être exécutée, une tâche activée s’exécute en entier. Par ailleurs, lorsque la file d’attente des
tâches est vide, le système d’exploitation met en veille le dispositif jusqu’au lancement de la prochaine
interruption,
Evènements
Les évènements sont prioritaires par rapport aux tâches et peuvent interrompre la tâche 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 tâches.
Signaler un event : signal Send.sendDone(&msg1, SUCCESS);
Commande
Une commande est l'exécution d’une fonctionnalité précise dans un autre composant.
Appeler une commande: call Send.send(1, sizeof(Message), &msg1);

14. LANGAGE NESC
 NESC est un langage conçus pour incarner les concepts structurant et le modèle d'exécution de TinyOS.
 fait pour minimiser l’utilisation de mémoire et de puissance de calcul par les capteurs, qui très souvent
disposent de ressources très limitées (batterie de faible puissance et non changeable, mémoire
réduite...).
 C'est une extension du langage C orientée composant ; il support alors la syntaxe du langage C et il est
compilé vers le langage C avant sa compilation en binaire.
Les fichiers dans NesC :
Les fichiers de NesC sont classés en trois types : Interfaces, modules et configurations.
Interface : Ce type de fichier déclare les services fournis et les services qui seront utilisés. Ils se trouvent dans le
répertoire /tos/interface. (exemple : StdControl.nc).
Module : Le type Module contient le code de l’application, en mettant en œuvre une ou plusieurs interfaces.
(exemple : BlinkM.nc).
Configuration : Dans ce fichier on déclare la manière d’unir les différents composants et comment effectuer le
contrôle des flux. (exemple : Blink.nc).

15. LANGAGE NESC
Composants
TinyOS définit un nombre important de concepts qui sont exprimés dans NesC . D’abord, les applications
NesC sont construites par des composants avec des interfaces bidirectionnelles d´définies.
 L'unité de code de base de nesC
 Un composant correspond à un élément matériel (LEDs, timer, ADC…) et peut être réutilisé dans différentes
applications.
Exécute des Commandes
Lance des Events
Dispose d'un Frame pour stocker l'état local
Utilise la notion de Tasks pour gérer la concurence
 Un Composant implémente des interfaces utilisées par d'autres composants pour communiquer avec ce
composant

16. LANGAGE NESC
Il existe deux types de composants :
 Module : composant implémenté avec du code (spécifications d’un composant) .
 Configuration : composants reliés ensemble en fonction des interfaces (commandes ou
événements)pour former un autre composant

17. LANGAGE NESC
Implémentation
Dans cette section on définit :
 quels sont les composants qui fournissent les interfaces à notre application .
les connections entre les différents composants qu’utilise l’application. deux composants sont reliés ensemble
en les connectant (wiring).
• endpoint1 = endpoint2 endpoint1 -> endpoint2 endpoint1 <- endpoint2
Configuration
C’est à cet endroit que l’on déclare les autres composants dont se servira l’application. Cette possibilité offerte
par le langage permet de faire de la programmation modulaire et de réutiliser des composants préalablement
définis.

18. LANGAGE NESC
Module
Cette partie du code est généralement plus étendue et c’est dans celle-ci que l’on programme réellement le
comportement qu’on souhaite voir réalise par l’application. Cette partie là est à son tour divisée en trois sous-
sections : Uses, Provides, Implementation.
// code

19. LANGAGE NESC
« provides » : indique au compilateur les interfaces que va fournir notre composant. Par exemple, si notre
composant est une application, on doit fournir au moins l’interface StdControl.
« uses » : informe le compilateur que nous allons faire usage d’une interface ,

20. LANGAGE NESC
Types de donnée
Les types de données qui peuvent être utilisés en NesC sont tous ceux que fournit le langage C standard plus
quelques autres qui n’apportent pas de puissance de calcul mais qui sont très utiles pour la construction de
paquets puisqu’ils fournissent à l’utilisateur le nombre de bits qu’ils occupent (ceci est important au moment
de la transmission des informations par l’intermédiaire des ondes radio).
Ces types additionnels sont :
 uint16_t : entier non signé sur 16 bits.
 uint8_t : entier non signé sur 8 bits.
 result_t : utilisé pour savoir si une fonction à été exécuté avec succès ou non, c’est comme un booléen mais
avec les valeurs SUCCESS et FAIL. (retour de fonction)

21. PROCESSUS DE COMPILATION
Le compilateur traîte les fichiers NESC en les convertissant en un fichier C. Ce fichier contiendra l'application et
les composants de l'OS utilisés par l'application. Ensuite un compilateur spécifique à la plateforme cible
compile ce fichier C. Il deviendra alors un seul exécutable. Le chargeur installe le code sur le "mote" (Mica2,
Telos, etc.)

22. SIMULATION
Le simulateur TOSSIM
TOSSIM est le simulateur de TinyOs « bibliothèque ». Il permet de simuler le comportement d’un capteur
(envoie/réception de messages via les ondes radios, traitement de l’information, …) au sein d’un réseau de
capteurs. Chaque répertoire source TinyOS possède un sous-répertoire sim facultatif, qui peut contenir des
implémentations de simulation de ce package.
Par exemple, tos/chips/atm128/timer/sim contient des implémentations TOSSIM de certaines des abstractions
du temporisateur Atmega128.
Actuellement, micaz est la seule plateforme prise en charge par TOSSIM. Vous devriez voir une sortie similaire
à ceci

23. SIMULATION
Le simulateur TinyViz
L’outil TinyViz est une application graphique qui nous permet d’avoir un aperçu de notre réseau sans avoir à
déployer les capteurs dans la nature.
Une économie d’effort et une préservation du matériel sont possibles grâce à cet outil. L’application permet
une analyse étape par étape en activant les différents modes disponibles (On/Off, Delay ,Play, Grilles ,Clear,
Arête )
fenêtre graphique TinyViz

24. LES TYPES DES CAPTEURS NŒUDS UTILISÉES
 TelosB
 MicaZ
 Iris
 Mica2
 Mica2Dot

25. ARCHITECTURE DES NOEUDS CAPTEURS
 TelosB
1. Processeur
- TI MSP430
- 8 MHz ,10kB RAM
2.Transmission
- IEEE 802.15.4 (ZigbBee)
- 250 Kbps
- Antenne intégrée
3. Flach
- 1 MB
4. Sensor
- Lumière
- Température
- Humidité
5. Système
- tinyOS

26. ARCHITECTURE DES NOEUDS CAPTEURS

27. ARCHITECTURE DES NOEUDS CAPTEURS
 MICAZ
1.RAM:
– Data memory :4 KOctets
2. ROM/Flash:
– program memory: 128 kOctets
3.External Flash: 512KB
4. Processeur:
– Atmel AVR Atmega 128 bit / 8MHz

28. ARCHITECTURE DES NOEUDS CAPTEURS
 MICA2dot
1. Size: 4 cm x 4 cm
2. CPU: 4 MHz, 8 bit
3. 512 Bytes RAM, 8KB ROM
4. Radio: 900 MHz, half-duplex
5. Serial communication
6. Sensors: Acceleration,
temperature, pressure, humidity,
light…

29. ARCHITECTURE DES NOEUDS CAPTEURS
 Mica2
1. 8-bit AVR Controller
2. FSK radio
3. Data-logger flash memory

30. TERRA- CÉU
 Code Blink LED

31. TERRA- CÉU
 Code des capteurs

32. TERRA- CÉU
 Code émission et réception des messages

33. SIMULATION DE CODE TERRA

34. CONCLUSION