Le langage NesC (Network Embedded System C) est un dialecte de C basé sur des composants. NesC est orienté pour satisfaire les exigences des systèmes embarqués. De plus, il supporte un modèle de programmation qui agrège l’administration des communications, les concurrences provoquant les tâches et les évènements ainsi que la capacité de réagir par rapport à ces évènements.
NesC réalise aussi une optimisation dans la compilation du programme, en détectant les carrières possibles de données qui peuvent produire des modifications concurrentes au même état, à l’intérieur du processus d’exécution de l’application. Une carrière de données se produit quand plus d’un fil peuvent simultanément accéder à la même section de mémoire (concurrence d’accès mémoire entre threads), et quand au moins l’un des accès est un ”write”.
NesC simplifie aussi le développement d’applications et réduit la taille du code qui est un critère important dans l’implémentation de code dans un capteur étant donné sa capacité de mémoire.
4.2 Les Principales caractéristiques de NesC
NesC est constitué d’interfaces et de composants. Une interface peut être utilisée ou peut être fournie. Les composants sont des modules ou des configurations.
4.3 Architecture d’une application
Figure 4.1 Architecture d’une application
4.3.1 Interface
Une interface peut être utilisée ou peut être fournie. Les composants sont des modules ou des configurations. Une application est représentée comme un ensemble de composants, regroupés et rattachés entre eux.
Les interfaces sont utilisées pour les opérations qui décrivent l’interaction bidirectionnelle. Le fournisseur de l’interface doit mettre en application des commandes, alors que l’usager de l’interface doit mettre en application des évènements.
4.3.2 Composant
Dans la pratique, NesC permet de déclarer deux types de composants : les modules et les configurations. Un module contient le code d’un composant élémentaire et implémente une ou plusieurs interfaces. Les interfaces sont des fichiers décrivant les commandes et évènements proposés par le composant qui les implémente. L’utilisation des mots clefs « Uses » et « Provides » au début d’un composant permet de savoir respectivement si celui-ci fait appel à (requiert) une fonction de l’interface ou redéfinit (fournit) son code. Une application peut faire appel à des fichiers de configuration pour regrouper les fonctionnalités des modules. Un fichier top-level configuration permet de faire le lien entre tous les composants.
4.3.2.1 Les modules :qui mettent en application des spécifications d’un composant.
4.3.2.2 Les configurations, qui se chargeront d’unir différents composants en fonction des interfaces (commandes ou évènements).
La figure suivante montre un diagramme de blocs dans lequel est décrit le processus de compilation pour une application TinyOS écrite en NesC :
Figure 4.2 processus de compilation
4.4 Processus de compilation
4.4.1 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.
4.4.2 Module
Le type Module contient le code de l’application, en mettant en œuvre une ou plusieurs interfaces.
4.4.3 Configuration
Dans ces fichiers on déclare la manière d’unir les différents composants et comment effectuer le contrôle des flux. (exemple : Blink.nc).
4.4.4 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éfinies. Aussi, NesC définit un modèle basé sur les tâches et les captures d’évènements matériels, et détecte des éclatements d’information pendant la compilation.
Un composant, du point de vue de la programmation, est composé de plusieurs sections et l’ensemble de toutes ces sections donne lieu à la création de ce composant.
4.5 Implémentations