Les systèmes basés sur les événements

In document en fr (Page 72-76)

capteurs sans fil

2.4 Les systèmes basés sur les événements

De part leur mode de fonctionnement, les systèmes d’exploitation pilotés par les événements sont adaptés aux RCSF [Stojmenovic 2005]. L’architecture de ce type de système est organisée autour des traitements à effectuer et de la gestion des ressources disponibles. Le système d’exploitation TinyOS, développé à l’Université de Californie de Berkeley, fait partie de cette famille de systèmes d’exploitation et permet d’en illustrer certaines caractéristiques communes [Hill 2000]. En outre, TinyOS représente un cadre pour le développement de systèmes d’exploitation dédiés aux RCSF.

2.4.1 L’architecture du système TinyOS

Les événements pris en compte et leurs réponses associées sont centraux dans TinyOS.

Sous ce système, une application est construite à partir de l’association et de l’empilement de différents composants. Ces derniers sont constitués des éléments suivants :

• un gestionnaire de commandes ;

• un gestionnaire d’événements ;

• une liste de processus associés ;

• un contexte d’exécution avec un espace mémoire de taille fixe.

Les commandes et les événements permettent à l’aide d’interfaces la communication entre les composants (voir Figure 2.10).

Figure 2.10 –Exemple de composant du système TinyOS avec ses interfaces [Hill 2000]

CemOA : archive ouverte d'Irstea / Cemagref

Les commandes, comme leur nom l’indique, sont des ordres ou des demandes adressés aux composants de niveau inférieur. A l’inverse, les événements se propagent à partir du matériel et remontent jusqu’à atteindre le composant de plus haut niveau de l’application (voir Figure 2.11).

Figure 2.11 – Eléments associés au composant précédent [Hill 2000]

Ces événements sont essentiellement matériels, initiés par des interruptions déclenchées par une horloge, un dispositif d’observation de grandeur physique ou un module de communication. Cependant, selon que l’on remonte l’arbre des composants formant une application, les événements peuvent rendre compte de la fin d’opérations effectuées sur les données (agrégation, formatage, etc.) et donc être considérés comme étant de type logiciel (voir Figure 2.12). On retrouve cet aspect dans la répartition des composants en trois catégories :

• les composants d’abstraction de niveau matériel ;

• les composants « synthétiques » de niveau matériel ;

• les composants de haut niveau logiciel.

Le rôle des composants d’abstraction de niveau matériel est l’intégration des dispositifs matériels dans le modèle basé sur les composants. Ceux-ci offrent aux composants de niveau supérieur des interfaces (commandes) pour la gestion des entrées/sorties tels que les ports série. Les composants « synthétiques » implémentent des opérations de base sur les données. Dans une application de communication [Levis 2004], un tel composant regrouperait en blocs d’octets les données reçues bit par bit provenant du composant d’abstraction. Tous les traitements ou fonctions élaborés, requis par l’application, sont contenus dans des composants de haut niveau logiciel. Ce type de composants contient les processus dédiés au routage, au cryptage et à l’agrégation de données.

CemOA : archive ouverte d'Irstea / Cemagref

Figure 2.12 – Les différents types de composants du système TinyOS

2.4.2 L’ordonnancement dans le système TinyOS

L’autre particularité du système TinyOS concerne sa politique d’ordonnancement des processus. Un événement matériel comme la réception d’un message va déclencher une réaction de la part du composant associé à la communication. Cette réaction va se matérialiser par l’exécution d’un ensemble de processus. Mais contrairement à un système multitâche, les processus vont s’exécuter successivement sans pouvoir être préemptés [Levis 2004]. Ce procédé permet d’une part d’éviter les changements de contexte potentiels qui ont lieu durant le passage d’un processus actif à un autre et implique donc une accélération de la vitesse de traitement. D’autre part, la quantité de mémoire nécessaire est réduite car, en supprimant les changements de contexte, les processus n’ont plus besoin d’un espace mémoire propre. Ils vont accéder chacun leur tour à l’espace mis à disposition au niveau du composant. A défaut de pouvoir être préemptés, les processus sous TinyOS sont interruptibles pour permettre l’interception des interruptions matérielles.

Le fonctionnement général du système TinyOS le rend très adapté aux applications d’acquisition de données et même de surveillance. Dès sa prise en charge, un événement va donner lieu à une suite de traitements qui ne s’arrêtera que lorsque la réponse souhaitée sera atteinte. Par conséquent, la réactivité du système TinyOS dépend essentiellement du nombre d’événements en attente, à un instant donné, et à l’absence d’erreurs dans l’implémentation des composants.

CemOA : archive ouverte d'Irstea / Cemagref

2.4.3 Les avantages et inconvénients du système TinyOS

Le noyau TinyOS propose une architecture modulaire innovante dédiée au RCSF auquel vient s’ajouter l’utilisation de la notion d’événement en lieu et place de celle plus répandue de processus. Ces éléments font du noyau TinyOS une alternative viable vis-à-vis des systèmes multitâches ce qui représente un avantage. De plus, les différents composants constituant ce système d’exploitation peuvent être ajoutés ou supprimés suivant les contraintes de l’application supportée. Ces composants sont d’autant plus nombreux que le noyau TinyOS bénéficie actuellement du soutien d’une communauté de recherche dynamique et assez importante. Parmi les composants logiciels de haut niveau disponibles, on peut citer le système d’interrogation de données TinyDB [Madden 2005].

A l’inverse, beaucoup de programmes sont développés pour être exécutés sous un système multitâche. Le portage de ces programmes, s’il est possible, n’en demeure pas moins complexe. De la même manière, des programmes développés pour fonctionner sous le noyau TinyOS pourront être difficilement utilisables sous un autre système d’exploitation. Enfin, comme nous le verrons plus en détails dans la partie 2.7, l’utilisation des événements peut poser quelques problèmes en ce qui concerne la réactivité du système d’exploitation.

CemOA : archive ouverte d'Irstea / Cemagref

In document en fr (Page 72-76)